Exploit Based On Leaked Windows Code Released

mischief writes "A post to Bugtraq from SecurityTracker.com reports an Internet Explorer 5 exploit that has been released based on the Win2K code leak: 'It is reported that a remote user can create a specially crafted bitmap file that, when loaded by IE, will trigger an integer overflow and execute arbitrary code.' Only affects IE 5 apparently, but still - it didn't take long!"

Comments

Re:huh

[LocoSpitz]

Do not mod parent down. He's pointing out text found in the article link. That is not flamebait.

Re:Smells

[Paladine97]

Well it's not really the image file running the commands. It's the browser that is loading the image. The browser reads bad image data and gets overwritten.

It's no hoax.

Re:Smells

[Oscaro]

Smells like you shoud read some documentation on buffer overflow techinques. Of course image files cannot run commands, but you can do some nice tricks if the program that is loading the file fails to check where the data is loaded. If the data is bigger than the allocated space, you can garble the stack in some funny way and actually craft a picture that gets to be executed (in some parts at least). Of course, doing something other that crashing the process is NOT easy, but...

Re:What the fuck?

[DjReagan]

That wouldn't work in this case. Overflowing a signed integer so that it wraps around to negative won't be picked up by checking if the value is greater. Using the correct datatype (unsigned int) would have been better.

(in fact, looking at the code snipped in the vulnerability notification, they do check against Offset > size of buffer)

Re:What the fuck?

[MoneyT]

IIRC early Apple computers actualy had a memory location called "MonkeyLives" or something like that, which was used for a program they called the monkey. The monkey program randomly entered commands and clicks and such for as long as the program was running. The problem was, sometimes it would shutdown the computer (by executing a shutdown, not by crashing it) so they created a memory location that when shutdown was called, it first checked that location to see if the monkey program was running, and would cancel the shutdown if it was.

Re:Text of advisory

[Anonymous Coward]

Could someone explain exactly what happens in this code that causes the overrun?

Yes. I'll assume you're familiar with the basic ideas of programming, but are unfamiliar with C, especially on x86. I'll also assume you're familiar with hexadecimal/binary notation, as I'll be using it.

on x86, a negative integer is represented somewhat oddly. In C, the 'int' datatype is signed, meaning it can represent 'negative' integers. Specifically, the way a 16 bit signed integer is represented on x86 (and hence, how C compilers for x86 are going to handle them) is this:

Convert -3 to positive, so we have 3.
3 is represented as this (16 bit signed integer) :
0x0003
or in binary - 0000 0000 0000 0011

to get the negative representation, we flip every bit and add 1. so, the representation of -3 in a 16 bit signed integer on x86 is:
1111 1111 1111 1100 + 1 = 1111 1111 1111 1101
which in hexadecimal is 0xFFFD. note that, 0xFFFD is large (relative to the max value 16 bits can hold). if treated as unsigned, specifically represents the number in base 10 as 65533.

now with that aside, we can easily spot the problem.

/* cbSkip represents a signed integer */
int cbSkip;

/* bfOffBits is supposed to be unsigned. */
cbSkip = _bmfh.bfOffBits - cbRead;

/* if bfOffBits say, contains 0xFFFF (-1)
than cbSkip _wont_ be greater than 1024,
note that this is supposed to prevent
too many bytes to be read! */
if (cbSkip > 1024)
cbSkip = 1024;

/* Since cbSkip contains 0xFFFF, which is '-1',
Read will attempt to read 0xFFFF bytes into
the buffer, which can only store 0x400 bytes.
Oops. */
if (!Read(abDummy, cbSkip))
goto Cleanup;

The technical reasons of why overwriting a buffer is bad, are beyond the scope of this post. Just know that it is one of the worst things that can happen ;)