MS releases MS06-002 and MS06-003

(Updated: January 10, 2006 on 7:40 pm, updated again: January 11, 2006 on 07:54 am)

Yes we are at that special day of the month, and like everything else, it comes better second time around :)

Microsoft has released MS06-002 (BTW… it was discovered 162 days ago) and MS06-003 a few minutes ago, both are categorized as critical, doesn’t that give you a waorm feeling?

MS06-002 was discovered by eEye, while MS06-003 was discovered NGS Software. This already tells me two things, for the eEye an abundance of technical material will be made available, while for NGS Software, literally no technical information will be uncovered. Unless like in the case of the recent WMF Spyware/Worm/Whateveryoucallit shenanigan, someone skilled enough will find how to exploit it on their own.

Some initial details on MS06-002: it also affects legacy software such as Windows 98, and requires the user to simply visit a malicious web site – much like the WMF vulnerability.

Some initial details on MS06-003: it affects Outlook 2000 and up, and can be easily exploited by sending someone a TNEF file (Transport Neutral Encapsulation Format).

More to come as I analyze these two vulnerabilities to gather additional information from the public and hax0r mailing lists (:D)…

eEye has released an advisory, from the advisory the following can be understood:
Embedded Open Type fonts are referenced through the use of style data, as the following snippet illustrates:

@font-face {
font-family: Abysmal;
font-style: normal;
font-weight: normal;
src: url(evil.eot);

The heap overflow vulnerability is found in the in T2EMBED.DLL, and:
The data within an EOT file is compressed in Agfa MicroType Express format, which hosts an LZ-compressed stream that includes a 24-bit allocation size. This size + 1C00h is allocated within the function MTX_LZCOMP_UnPackMemory, but the resulting allocation size is not validated before data is copied into the block, allowing a malformed EOT file to cause an essentially arbitrary-length heap buffer overflow with binary data.

Sounds simple enough to exploit… let the countdown begin.

Update 2:
A very technical and detailed explaination on the vulnerability can be found at:

  • Matthew Murphy

    Spot-on about the level of technical detail. Couldn’t be more accurate. Ever since NGS got burned by Slammer, they’ve practically quit releasing details. It’s really a shame.