A specially crafted web-page can cause Microsoft Internet Explorer to assume a
CSS value stored as a string can only be "true"
or "false"
. To determine
which of these two values it is, the code checks if the fifth character is an
'e'
or a "\0"
. An attacker that is able to set it to a smaller string can
cause the code to read data out-of-bounds and is able to determine if a WCHAR
value stored behind that string is "\0"
or not.
MSIE 9-11 (earlier versions were not tested)
An attacker would need to get a target user to open a specially crafted webpage. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path.
Certain code that handles CSS properties in MSIE assumes that the property
value is always a string set to either "true"
or "false"
. To determine
which of these two values it is, the code checks if the fifth character is
'\0'
. However, it is possible to set such values to arbitrary strings,
including a smaller string. This causes the code to read beyond the end of the
string and allows an attacker to determine if an WORD stored after the string
is '\0'
.
The vulnerable code is in MSHTML!PROPERTYDESC::
.
This code is heavily branched to handle various types of CSS properties.
Luckily, the type being exploited is one of the first to be handled. The code
appears to assume that the value is provided as a pointer to a BSTR
which
will always have a WCHAR
at offset +8 that may be '\0'
or not. If this
WCHAR
is not '\0'
, a CSS property is set to a certain value, otherwise it
is set to an empty string. As long as this BSTR
is always either be "true"
or "false"
, this code works as expected. However, it is possible to provide
an arbitrary value for this BSTR
, which can be shorter than 4 WCHARs
. This
would causing the code to read a WCHAR
outside of the memory used to store
that BSTR
.
In the repro, we used Heap Feng-Shui to put a BSTR
containing 3 WCHARs
in the OLEAUT32
cache. This causes MSIE to allocate 12 byte of memory to
store the string: 4 bytes to store the DWORD
length of the BSTR
, 6 to store
the characters, and 2 to store a "\0" terminator. This memory is then reused to
store a 1 WCHAR
string "x"
. When the code attempts to check if the fifth
character in this his BSTR
is '\0'
, it will attempt to read the two bytes
at offset 14 (The characters are stored at offset 4, after the DWORD
length,
and the fifth character is at offset 10
from the first). This causes the code
to read outside of the bounds of that BSTR
and trigger an access violation.
(On x86 systems, page heap will provide some padding at the end of the string,
causing the code to read these padding bytes, so no AV happens).
Known properties of the type that leads to the vulnerable code path include
textDecorationBlink
, textDecorationLineThrough
, textDecorationLineNone
,
textDecorationOverline
, and textDecorationUnderline
.
The value of a CSS property is updated based on the value of the fifth WCHAR
,
and this CSS property can be read from Javascript to determine if this WCHAR
was '\0'
or not. This allows a limited form of information disclosure. During
my testing, I used the textDecorationBlink
property, which can be used to set
the CSS text-decoration
property to "blink"
or an empty string.
Using Heap-Feng Shui, it may be possible to reuse memory allocated for other
strings that have since been freed and determine if they had a '\0'
WCHAR
as their fifth character. This includes strings to should normally not be
accessible to the website, such as those from a different origin. Also using
Heap Feng-Shui, it may be possible to allocate some interesting object
immediately following the string, in order to determine if a WORD
at the
start of that object is 0 or not.
The "exploit" provided below shows that it is possible to determine if the
fifth WCHAR
of the last freed BSTR
was '\0'
or not.
Id: 0F5F AVR:OOB iexplore.This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version.exe!MSHTML. dll!`CBackgroundInfo:: Property...>'::`7'::`dynamic atexit destructor for 'fieldDefaultValue'' Description: Access violation while reading memory at 0x625960D000; 0/0x0 bytes beyond a 16/0x10 byte memory block at 0x625960CFF0 Process binary: iexplore. exe Code: MSHTML. dll!`CBackgroundInfo:: Propertyy '::`7'::`dynamic atexit destructor for 'fieldDefaultValue'' + 0xA9CFA (this may not be correct) Security impact: Potentially exploitable security issue