Quoting http://msdn.microsoft.com/en-us/library/aa930622.aspx: "If the bitmap is a packed bitmap (a bitmap in which the bitmap array immediately follows the BITMAPINFO header and is referenced by a single pointer), the biClrUsed member must be either zero or the actual size of the color table."

The DWORD biClrUsed member of the BITMAPINFOHEADER can be used to cause MSIE to allocate any number of bytes and attempt to copy any ammount of data from the file in memory to the memory allocated.

This can be used to cause a read access violation because the memory copy operation can continue to read beyond the memory allocated for the file data and can run into unallocated memory (example value: 0x200000). The read AV is handled by an exception handler, so it does not affect the browser. It is only visible if a debugger is attached to MSIE.

This can also be used to cause MSIE to allocate excessive amounts of memory and become unresponsive, using 100% CPU. This seems to affect the x86 version of MSIE only. I have not investigated the exact cause of this.

Attached: repro.py: a Python script that can be used to generate .ANI files that repro the issue, repro.html: generated HTML file that can be used to load the .ANI icons, repro 0x200000.ani: an .ANI file that reproduces the read AV. repro 0x3F000000.ani: an .ANI file that reproduces the excessive memory use.

It seems the excessive memory use only causes issues if you have enough memory available. An attacker could create multiple .ani files using different large sizes to make sure any target system is affected.

Email sent to MSRC today.

FuzzFramework IDs: CopyDibHdr memcpy ReadAV@Arbitrary (98e6ff2a3aa140c08afc1ff767290e58) CopyDibHdr memmove ReadAV@Arbitrary (98e6ff2a3aa140c08afc1ff767290e58)

Attached debugger info

20 January, 2010: Reply from MS: Hello SkyLined,

Thank you for reporting this to us. I have opened MSRC case 9754 to track this issue.
Jack will be the case manager.

Best Regards, Nate

29 Januari, 2010, reply from MS: Hey SkyLined,

The investigation into MSRC Case [9754jr] has completed. We were able to reproduce the issue you reported, and can confirm that it results in a Denial of Service as you stated in your email. As a stability issue this is typically handled as a Next Version fix at the discretion of the product team. I will work with the product team to file bugs for their tracking. Thank you for reporting this issue to us.

Take care!

Jack MSRC

1 Februari, 2010: Reply to MS: Any idea on a timeframe?

Cheers, BJ

3 februari, 2010: Reply from MS: They have begun the planning and initial coding, but it will be a while yet before it releases with IE8 less than a year old. It’s far enough out that I don’t have an estimate.

Regards,

Jack MSRC

19 Febrauri, 2010: Follow-up from MS: Hi SkyLined,

I was discussing this issue the other day and discovered that I mistakenly identified the wrong group responsible for the fix. The issue is actually handled by the windows product team, but doesn't repro on Windows 7. If the binary in question was owned by IE, then it would be handled in the next version, however since the binary in question is handled by Windows, and the issue doesn't reproduce in the latest version, then I will document the case a service pack issue. The case is then at the product teams discretion to include in the service pack or not based on prioritization of all cases. Sorry for any confusion I may have caused, but I wanted to make sure to straighten out the case details with you.

Regards,

Jack MSRC

Renaming because the vulnerable component is in Windows. This should affects any software that uses that component to decode .ANI files.

1 March 2010, Reply to MS: Hi Jack,

If I understand you correctly, the .ANI parser that is affected by this vulnerability is part of Windows and not MSIE.

That would mean all software that depends on the Windows API for parsing .ANI files is affected. From what I can tell, MSIE wraps the API calls in an exception handler, which other software may not. I have not identified or tested other software, but I expect this means other software may not survive trying to load a malicious crafted .ANI file.

Considering this, are you still planning to fix this in a Service Pack for affected versions of Windows? Do you have a time frame for the release of the fix?

Cheers, BJ

3 March 2010, Reply from MS: Hi SkyLined,

You are correct, the .ANI parser affected is maintained by the windows team. During the investigation, the teams looked at the parser and determined that there are checks in place which prevent an Integer Overflow, and that the biggest potential impact is a Denial of Service which doesn’t meet the bar for a bulletin release. Instead, as a stability issue which does not affect the latest version, Windows 7, this case will be documented as a Service Pack fix to be addressed at the product teams discretion. Since the Service Packs themselves are managed completely by the product team I’m unfortunately unable to provide a release estimate as I don’t have that information. Please let me know if you have any additional questions or concerns about the case.

Highest Regards,

Jack MSRC

Published @ http://skypher.com/index.php/2010/03/08/ani-file-bitmapinfoheader-biclrused-bounds-check-missing/