MS10-001 addresses a vulnerability (CVE-2010-0018 ) in the LZCOMP de-compressor for Microtype Express Fonts. This blog aims to answer some questions regarding the updates we’ve made in this area.
What is the issue? t2embed.dll improperly performs bounds-checking on lengths which are decoded from the LZCOMP bit-stream. This made it possible for a copy loop to violate the intended working buffer.
Is the EOT functionality reachable through 3rd party code? Yes, the t2embed library provides EOT functionality that can be used by 3rd party code. Many 3rd parties import t2embed for their font rendering, though some may choose to implement their own font rendering.
Why an Exploitability Index rating of 2? The Exploitability Index rating or 2 is due to the low likelihood of successful exploitation. Hurdles exist around heap preparation and predictability, heap data corruption, and a race condition to get an exception handler making successful exploitation unlikely.
What is the likelihood of successful exploitation? Due to the nature of bounds-checking performed in t2embed on 32-bit systems XP and later, the only buffer+index combinations which would pass the old checks will point into address 0x80000000 and above. Because these regions cannot be accessed while running at IOPL 3, the process will crash (Access Violate) and the attempt to run arbitrary code would fail.
On Windows 2000, this vulnerability could be abused to leverage code execution. On 32-bit platforms post Windows 2000, improper memory access would commonly be observed in the form of a Read Access Violation at address 0x80000000 or above, though the memory layout on /3GB-enabled systems could be manipulated to compromise the integrity of the hosting process. Stability (Denial of Service) implications exist on these systems when /3GB is not enabled (default), whereas /3GB-enabled systems run a risk of code execution, though no known attack vectors exist in Microsoft products.
Third party products which are (A) large address aware (http://msdn.microsoft.com/en-us/library/wz223b1z(VS.80).aspx), (B) consume the t2embed, and are (C) running on a /3GB-enabled system should be considered exploitable.
On 64-bit platforms, improper memory access would commonly be observed in the form of a Read Access Violation at a kernel mode address which would affect application stability (Denial of Service) with no threat of code-execution.
Here is a table to represent the exploitation scenarios described above:
| /2GB not running Large Address Aware Application | /3GB not running Large Address Aware Application | /2GB running Large Address Aware Application | /3GB running Large Address Aware Application | |
|---|---|---|---|---|
| 32-bit XP and newer | Denial of Service | Denial of Service | Denial of Service | Chance for Code Execution |
| 64-bit XP and newer | Denial of Service | Denial of Service | Denial of Service | Denial of Service |
| Windows 2000 | Chance for Code Execution | Chance for Code Execution | Chance for Code Execution | Chance for Code Execution |
The Windows 2000 severity rating of critical was chosen due to the vulnerable code being exposed through client applications that can render EOT fonts in a way that does not require user interaction/notification. (such as Microsoft Internet Explorer, Microsoft Office PowerPoint, and Microsoft Office Word)
What are the attack vectors? Remote attack vectors are all in user-mode:
- Malicious fonts (EOT) delivered within files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.
- Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).
How do I protect myself? The best option for protecting against this vulnerability is to apply the update for MS10-001.
As stated in a previous SRD blog post, another option is to disable support for parsing/loading embedded fonts in IE. The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly.
What is /3GB and how can I tell if /3GB is enabled on my system? /3GB is a switch and it allows 32-bit systems to benefit from 3GB of addressable memory versus the default 2GB of memory. More information on /3GB can be found here. You can check to see whether you have /3GB enabled on your system by typing the following command in a shell:
C:\>bcdedit.exe /v
Windows Boot Manager
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {4a81cc63-2e99-11de-a190-00188b749f31}
resumeobject {4a81cc62-2e99-11de-a190-00188b749f31}
displayorder {4a81cc63-2e99-11de-a190-00188b749f31}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 30
Windows Boot Loader
-------------------
identifier {4a81cc63-2e99-11de-a190-00188b749f31}
device partition=C:
path \Windows\system32\winload.exe
description Microsoft Windows Vista
locale en-US
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
bootdebug Yes
osdevice partition=C:
systemroot \Windows
resumeobject {4a81cc62-2e99-11de-a190-00188b749f31}
nx OptIn
increaseuserva 3072
debug No
Note the increaseuserva variable. If unset (or set to 2048), you do not have /3GB enabled. If this value is set to 3072 (as seen here) you have /3GB enabled.
What is LZCOMP? LZCOMP is a compression algorithm variation of the LZ77 theme. A great explanation of LZCOMP and how it differs from LZ77 can be found here.
Where does the LZCOMP de-compressor component reside on my system? The LZCOMP de-compressor exists within the t2embed dynamically linked library. It commonly resides in %SystemRoot%\System32 and is imported by programs such as Office and Internet Explorer.
How does this Fonts vulnerability differ from the previous Fonts vulnerability addressed by MS09-065? This vulnerability exists in a user-mode component (t2embed.dll) whereas the previous Fonts vulnerability (MS09-065) addressed a kernel-mode component (win32k.sys).
I’d like to thank Matt Miller for general guidance, Bruce Dang and Robert Hensing from the MSRC Engineering Team for their efforts on this release.
-Brian Cavenah, MSRC Engineering
*Posting is provided “AS IS” with no warranties, and confers no rights.*