Hi everyone, I would like to make some comments about the Microsoft MS14-006 update. In the last February Patch Tuesday, Microsoft released a fix for the TCP Windows driver (tcpip.sys). According to the patch bulletin "https://technet.microsoft.com/en-us/security/bulletin/ms14-006" only Windows 8 and Windows 2012 were vulnerable. Diffing Windows 8, more exactly "tcpip.sys" version 6.2.9200.16659 vs "tcpip.sys" version 6.2.9200.16754 I found several patched functions like these:
- - Ipv6pSendRouterAdvertisementOnSubInterface
- - Ipv6pHandleRouterAdvertisement
- - Ipv6pUpdateSitePrefix
- - etc
Looking at the "Microsoft Security Research and Defense Blog" ("http://blogs.technet.com/b/srd") I found a comment about how to exploit the TCP bug: "Attacker on the same subnet as victim (IPv6 link-local) sends large number of malicious router advertisements resulting in victim system bugcheck." As key notes I found this: "This bugcheck is triggered by a watchdog timer on the system, not due to memory corruption. Affects Windows RT, Windows Server 2012 (not R2), and Windows 8 (not 8.1)." Trying to understand where the watchdog timer is, I decided to put focus in the "Ipv6pUpdateSitePrefix" function. The "Ipv6pUpdateSitePrefix" function First at all, it's important to say that the "Ipv6pUpdateSitePrefix" function is present in all Windows versions, both 32 and 64 bits version, and it's executed when IPv6 is enabled. Looking at changed functions I noted that the "Ipv6pUpdateSitePrefix" function had a security patch. Essentially, this fix added a comparision against the number 10. 10 of what ? Well, it took me little time to find the answer. This function processes "prefix" addresses sent by routers. If the "prefix" address is not in the "prefix address list", it will be added. What is a prefix address sent by a router in a "Router Advertisement" message ? You can find information here: "http://tools.ietf.org/html/rfc4862"
The Bug Now, I'll say that again: each new prefix address will be added to a list in memory if it's not already found on this. It means that if 1 million different prefix addresses are sent by routers, attackers, etc., this function will repeat the process for each prefix received ending in CPU and/or MEMORY exhaustion. After confirming my suspicions, I realized that the comparison with the number 10 added by the patch is the limit of elements to be added in this list. It's important to clarify that the target doesn't check if the "Router Advertisement" packet is sent by a real router, so putting a fake source address in the ICMPv6 packet is enough. Things became interesting when I checked the Windows 7 kernel ... The Unpatched Bug When I decided to check "tcpip.sys" in Windows 7, I noticed that the check against the number 10 wasn't there. Looking at Microsoft's Non-affected software list I could see that: When I finished the first exploit version, I launched it against my Windows 7 and the result was my computer with its CPU running at 100%, without memory to process anything, without network response and without a fix ... Improving the attack, if each packet to be sent has the "Autonomous address-configuration flag" enabled, the target will die much faster. At that moment, Core decided to send an email to Microsoft reporting this behavior, and the answer was something like this: "We fixed this bug because Windows 8 and Windows 2012 could produce a BSOD, but the rest of the OSs not" ... nice ... Their reply included this link: "http://www.mh-sec.de/downloads/mh-RA_flooding_CVE-2010-multiple.txt", explaining that this bug was reported before there. If you follow that link, at the end of the "Overview" section you can see a funny comment. Another use for this Bug It's easy to understand that if a target receives an attack like the one described, in few minutes it won't respond to UI interaction, network requests, etc. even if it has multiple cores ... But there's another very interesting use for this vulnerability. As I said before, if a prefix address is not in the prefix address list, it will be added. Now, in Windows 32 bit versions, each new prefix address to add will use 0x28 bytes in the kernel memory. It means that, if I send 1 million addresses, it will use 1.000.000 x 0x28 = 38MB of kernel memory but if I send 54 million it will use about 2GB ... danger ... the 32 bit Windows kernel can't address more that 2GB. During the attack, if we take a snapshot of the Windows's kernel heap, we can find something like that: Consecutive chunks ("NPpt" and "Ipng") allocated in the same kernel address page: The content of the kernel address page: You can see a highlighted line where the content is a prefix sent by the exploit, in this case, the prefix address is: "4141:4141:0003:db70:4141:4141:4141:4141". A very similar pattern is repeated in all the content of the memory page and in the most mapped memory kernel pages. Besides, other controlable values can be found in the same memory chunk. As a consequence, this bug can be used as a heap spray method to fill the kernel memory. Although it's not very useful by itself but it could be combined with another vulnerability resulting in what could be a very reliable attack. I remember some critical remote vulnerabilities where a good remote kernel heap spray was necessary to make a reliable exploitation (E.g "http://technet.microsoft.com/en-us/security/bulletin/ms12-020"). Linux is vulnerable too These days this vulnerability was also reported in Linux, with CVE-2014-2309 assigned to it. Some interesting links about the Linux vulnerability: * http://www.openwall.com/lists/oss-security/2012/10/10/8 * http://permalink.gmane.org/gmane.comp.security.oss.general/12309 * http://seclists.org/oss-sec/2014/q1/526 Below you can see the result of the same exploit against "Ubuntu 13.04 32 bits" Final notes You can see that this bug was reported before, not only to Microsoft, but nobody paid close attention. Many OS's kernel are still vulnerable. I would like to believe that a memory list in kernel without a size limit should be considered a security bug when an attacker is able to freeze the target by sending a big number of crafted packets. Nicolas Economou