Windows Animated Cursor Handling
Monday 2nd April, 2007 11:39 Comments: 5
Microsoft's ongoing monitoring of the situation has identified an increase in the number of attacks against this vulnerability, and because of public disclosure of proof-of-concept code, they have been working around the clock to test a security update that they are currently planning to release on Tuesday April 3 (a week before the usual monthly release).
The issue was first brought to Microsoft's attention in late December 2006, and was previously scheduled for release as part of April's monthly release on the 10th, but I'm a bit surprised that it's taken them this long to come up with the patch. The WMF vulnerability just over a year ago was identified over the New Year, yet they were able to come out with an "out of band" patch very quickly. This recent vulnerability is probably just as technically difficult to fix. I presume that, despite being a critical vulnerability, Microsoft handled it as a low priority problem because they hadn't seen any attacks. With their people now working around the clock, you have to wonder if they made the wrong business decision, especially when it's put so many users in jeopardy.
Except perhaps me, as I use Protected Mode on Vista, and enable DEP. I don't get why so many people find UAC annoying, or feel the need to disable it.
The issue was first brought to Microsoft's attention in late December 2006, and was previously scheduled for release as part of April's monthly release on the 10th, but I'm a bit surprised that it's taken them this long to come up with the patch. The WMF vulnerability just over a year ago was identified over the New Year, yet they were able to come out with an "out of band" patch very quickly. This recent vulnerability is probably just as technically difficult to fix. I presume that, despite being a critical vulnerability, Microsoft handled it as a low priority problem because they hadn't seen any attacks. With their people now working around the clock, you have to wonder if they made the wrong business decision, especially when it's put so many users in jeopardy.
Except perhaps me, as I use Protected Mode on Vista, and enable DEP. I don't get why so many people find UAC annoying, or feel the need to disable it.
Robert - Monday 2nd April, 2007 11:46 For the geeks out there, here's some info about the various patches that have been released by X-Solve, eEye and ZERT:
The newly discovered zero-day vulnerability in the parsing of animated cursors is very similar to the one previously discovered by eEye that was patched by Microsoft in MS05-002. Basically an anih chunk in an animated cursor RIFF file is read into a stack buffer of a fixed size (36 bytes) but the actual memory copy operation uses the length field provided inside the anih chunk—giving an attacker an easy route to overflow the stack and gain control of the execution of the process.
With the MS05-002 patch, Microsoft added a check for the length of the chunk before copying it to the buffer. However, they neglected to audit the rest of the code for any other instances of the vulnerable copy routine. As it turns out, if there are two anih chunks in the file, the second chunk will be handled by a separate piece of code which Microsoft did not fix. This is what the authors of the zero-day discovered.
Although eEye has released a third-party patch that will prevent the latest exploit from working, it doesn't fix the flawed copy routine. It simply requires that any cursors loaded must reside within the Windows directory. This approach should successfully mitigate most drive-by's from the web, but might be bypassed by an attacker with access to this directory.
For this reason, ZERT and X-Solve have released patches which addresses the core of the vulnerability, in the former case the patch ensures that no more than 36 bytes of an anih chunk will be copied to the stack buffer, thus eliminating all potential exploit paths while maintaining compatibility with well-formatted animated cursor files.
And for those that are relying on Snort rules to protect themselves, it seems that the original bleeding edge rule for the ANI exploit doesn't catch the vulnerability as it tries to track the exploit being used instead. It appears that a newer version of the rule now exists, but it still won't catch the vulnerability either, as the anih blocks don't necessarily need to be close by to each other, and you could place a valid anih block between them and the crash will still happen.
The newly discovered zero-day vulnerability in the parsing of animated cursors is very similar to the one previously discovered by eEye that was patched by Microsoft in MS05-002. Basically an anih chunk in an animated cursor RIFF file is read into a stack buffer of a fixed size (36 bytes) but the actual memory copy operation uses the length field provided inside the anih chunk—giving an attacker an easy route to overflow the stack and gain control of the execution of the process.
With the MS05-002 patch, Microsoft added a check for the length of the chunk before copying it to the buffer. However, they neglected to audit the rest of the code for any other instances of the vulnerable copy routine. As it turns out, if there are two anih chunks in the file, the second chunk will be handled by a separate piece of code which Microsoft did not fix. This is what the authors of the zero-day discovered.
Although eEye has released a third-party patch that will prevent the latest exploit from working, it doesn't fix the flawed copy routine. It simply requires that any cursors loaded must reside within the Windows directory. This approach should successfully mitigate most drive-by's from the web, but might be bypassed by an attacker with access to this directory.
For this reason, ZERT and X-Solve have released patches which addresses the core of the vulnerability, in the former case the patch ensures that no more than 36 bytes of an anih chunk will be copied to the stack buffer, thus eliminating all potential exploit paths while maintaining compatibility with well-formatted animated cursor files.
And for those that are relying on Snort rules to protect themselves, it seems that the original bleeding edge rule for the ANI exploit doesn't catch the vulnerability as it tries to track the exploit being used instead. It appears that a newer version of the rule now exists, but it still won't catch the vulnerability either, as the anih blocks don't necessarily need to be close by to each other, and you could place a valid anih block between them and the crash will still happen.
The other question is should users really be worried? Yes, they should (after all, it is a critical vulnerability), but I wouldn't stop using the net because of it. It seems that the majority of computer infections are still caused by malware that's over 3 years old. Figures compiled by Sophos's global network of monitoring stations show that the Netsky family has had the biggest impact on computer users last month, accounting for almost a third of all malware seen during March. Netsky's return to the top comes despite protection against this family of worms having been available for more than three years. Netsky accounted for 32.7%, Mytob accounted for 30.4%. Considering how old these threats are, those percentages are outrageous.
According to the Metasploit blog, there's been some discussion going around about whether or not it's really possible to use the ANI vulnerability to execute arbitrary code on Vista. The recent post focuses on illustrating that code execution on Vista is most definitely possible. Many would assume that this vulnerability would be stopped by one or more of GS, DEP, ASLR, and Protected Mode IE7 on Vista. That's not the case, though.
The vulnerable function does not properly make use of GS. This makes it possible to trigger a traditional stack-based buffer overflow on all affected versions of Windows. In addition to GS not being present, DEP is disabled by default for Internet Explorer and Windows Explorer on 32-bit Windows Vista (x64 users have DEP enabled by default and I think will therefore be safe, 32-bit users can enable protection by changing system settings and rebooting). This means that non-executable pages will not be enforced. And that brings us to ASLR.
On the surface, it would seem as though ASLR would be sufficient to prevent this attack from working reliably. However, due to the nature of this vulnerability, it's possible to trigger a partial overwrite of the return address on the stack. In Vista, and indeed other versions of Windows, the two low order bytes of any address in an image file mapping will not be affected by ASLR. This is due to the minimum allocation granularity in Windows. Even though partial overwrites of the return address are possible, an attacker must be able to find a useful instruction on the same 16 page block as the return address being partially overwritten. For example, if the original return address was 0x74310368, a useful instruction must be found within 0x7431XXXX. An alternative to using a partial address overwrite would be to simply brute force around 256 combinations of absolute addresses, since it's possible to trigger this issue multiple times without crashing the IE process.
It has been proposed that Protected Mode in IE7 on Vista may prevent the exploitation of this issue. This is not true. While it may prevent the explicit execution and interaction with certain system resources, it does not prevent arbitrary code execution (the vulnerability allows an attacker to write directly to the stack, essentially bypassing IE's control/protection because the exploit does not spawn any external processes on its own). The Metasploit blog also says that further research may provide insight into ways of breaking out of protected mode.
The vulnerable function does not properly make use of GS. This makes it possible to trigger a traditional stack-based buffer overflow on all affected versions of Windows. In addition to GS not being present, DEP is disabled by default for Internet Explorer and Windows Explorer on 32-bit Windows Vista (x64 users have DEP enabled by default and I think will therefore be safe, 32-bit users can enable protection by changing system settings and rebooting). This means that non-executable pages will not be enforced. And that brings us to ASLR.
On the surface, it would seem as though ASLR would be sufficient to prevent this attack from working reliably. However, due to the nature of this vulnerability, it's possible to trigger a partial overwrite of the return address on the stack. In Vista, and indeed other versions of Windows, the two low order bytes of any address in an image file mapping will not be affected by ASLR. This is due to the minimum allocation granularity in Windows. Even though partial overwrites of the return address are possible, an attacker must be able to find a useful instruction on the same 16 page block as the return address being partially overwritten. For example, if the original return address was 0x74310368, a useful instruction must be found within 0x7431XXXX. An alternative to using a partial address overwrite would be to simply brute force around 256 combinations of absolute addresses, since it's possible to trigger this issue multiple times without crashing the IE process.
It has been proposed that Protected Mode in IE7 on Vista may prevent the exploitation of this issue. This is not true. While it may prevent the explicit execution and interaction with certain system resources, it does not prevent arbitrary code execution (the vulnerability allows an attacker to write directly to the stack, essentially bypassing IE's control/protection because the exploit does not spawn any external processes on its own). The Metasploit blog also says that further research may provide insight into ways of breaking out of protected mode.
http://www.milw0rm.com/exploits/3636
..::[ jamikazu presents ]::..
Windows Animated Cursor Handling Exploit (0day) (Version3)
Works on fully patched Windows Vista
I think it is first real remote code execution exploit on vista =)
Tested on:
Windows Vista Enterprise Version 6.0 (Build 6000) (default installation and UAC enabled)
Windows Vista Ultimate Version 6.0 (Build 6000) (default installation and UAC enabled)
Windows XP SP2
(It also must to work on all nt based windows but not tested)
Update: It also bypass eeye security ani patch!
Author: jamikazu
Mail: jamikazu@gmail.com
Bug discovered by determina (http://www.determina.com)
Credit: milw0rm,metasploit, SkyLined, http://doctus.net/
invokes calc.exe if successful
Windows Animated Cursor Handling Exploit (0day) (Version3)
Works on fully patched Windows Vista
I think it is first real remote code execution exploit on vista =)
Tested on:
Windows Vista Enterprise Version 6.0 (Build 6000) (default installation and UAC enabled)
Windows Vista Ultimate Version 6.0 (Build 6000) (default installation and UAC enabled)
Windows XP SP2
(It also must to work on all nt based windows but not tested)
Update: It also bypass eeye security ani patch!
Author: jamikazu
Mail: jamikazu@gmail.com
Bug discovered by determina (http://www.determina.com)
Credit: milw0rm,metasploit, SkyLined, http://doctus.net/
invokes calc.exe if successful
It seems there is a good reason why it took Microsoft so long to release a patch: there was a bug with a RealTek audio control panel. This bug happened because of something wrong in RealTek's code, not Microsoft's code.
When Microsoft tests a patch prior to shipping, they also test popular third party applications, something that most people don't realise. When they encounter such an issue, they change their patch until the 3rd party bug no longer appears. In some cases, they have changed the Windows specification just to fix bugs in a popular application. Microsoft doesn't publicise this, but it happens a lot. What appears to be "Microsoft's fault" is actually Microsoft covering for other vendors.
Ys it took Microsoft a week to ship a bug fix for an actively exploited bug, but they tested it on 30 different versions of Windows (various patch levels, 2k/XP/2003/Vista, Itanium/x86/x64) and thousands of apps - all in under a week!
Others can create pseudo-patches (in the case of eEye, it was a fudge rather than a fix) for such bugs is the don't have to suffer any consequences
When Microsoft tests a patch prior to shipping, they also test popular third party applications, something that most people don't realise. When they encounter such an issue, they change their patch until the 3rd party bug no longer appears. In some cases, they have changed the Windows specification just to fix bugs in a popular application. Microsoft doesn't publicise this, but it happens a lot. What appears to be "Microsoft's fault" is actually Microsoft covering for other vendors.
Ys it took Microsoft a week to ship a bug fix for an actively exploited bug, but they tested it on 30 different versions of Windows (various patch levels, 2k/XP/2003/Vista, Itanium/x86/x64) and thousands of apps - all in under a week!
Others can create pseudo-patches (in the case of eEye, it was a fudge rather than a fix) for such bugs is the don't have to suffer any consequences