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.

Text of advisory

[Anonymous Coward]

I downloaded the Microsoft source code. Easy enough. It's a lot
bigger than Linux, but there were a lot of people mirroring it and so
it didn't take long.

Anyway, I took a look, and decided that Microsoft is GAYER THAN AIDS .
For example, in win2k/private/inet/mshtml/src/site/download/imgbmp .cxx:

// Before we read the bits, seek to the correct location in the file
while (_bmfh.bfOffBits > (unsigned)cbRead)
{
BYTE abDummy[1024];
int cbSkip;

cbSkip = _bmfh.bfOffBits - cbRead;

if (cbSkip > 1024)
cbSkip = 1024;

if (!Read(abDummy, cbSkip))
goto Cleanup;

cbRead += cbSkip;
}

.. Rrrrriiiiggghhhttt. Way to go, using a signed integer for an
offset. Now all we have to do is create a BMP with bfOffBits > 2^31,

and we're in. cbSkip goes negative and the Read call clobbers the
stack with our data.

See attached for proof of concept. index.html has [img src=1.bmp]
where 1.bmp contains bfOffBits=0xEEEEEEEE plus 4k of 0x44332211.
Bring it up in IE5 (tested successfully on Win98) and get
EIP=0x44332211.

IE6 is not vulnerable, so I guess I'll get back to work. My Warhol
worm will have to wait a bit... .gta
PROPS TO the Fort and HAVE IT BE YOU.

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 ;)

Re:Text of advisory

[dylan_-]

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 ;)

I'll have a go at a simple explanation....

The data fills up all the room that was allocated for it and then carries on. You make sure there's enough that it overwrites a special bit of memory called the EIP which tells the computer where the next intruction in memory is. So you make sure the data that lands in the EIP points to the data (actually instructions) you've kindly provided! Whatever process you've overrun has now been hijacked and your code is running. Make sense?

Re:Text of advisory

[PhilHibbs]

that it overwrites a special bit of memory called the EIP

No, it doesn't overwrite the EIP, that's a register in the CPU. What it does overwrite is the return address that was pushed onto the stack when the function was called, so instead of returning to the calling code, it returns to the exploit code.

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)

Wrong

[Moth7]

a)The jpeg virus "hoax" was down to IE interpretting a jpeg as a VBS file. That's perfectly normal - if you name a shell script "harmless_image.jpeg", provided the shell sees the #!/usr/bin/shell line, then it's going to see a script and execute it as such.
b)You wouldn't think that an overly long PASS string sent to an ftp server would be able to execute commands - but it can. If you can overflow a buffer and force it to work it's way back up the stack then you could convince mouse gestures to execute commands.

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.

No, the FS/OS world does not insist on upgrades

[JoeBuck]

No, it doesn't work that way. All the major Linux and BSD distros backport security fixes into older apps that they have released; they do not insist that you upgrade to the next major version. When someone (e.g. Red Hat) drops security coverage for older versions, multiple efforts (Progeny, Fedora Legacy) spring up to fill the gap.

Re:Open Source More Secure... maybe not

[drinkypoo]

Here's a nice supporting example for you: One of my buddies brought up a machine, got a DHCP response from the wrong place, and got railroaded to some site that looked like it was selling knives, instead of windows update. Turned out it was a page with a DSO exploit in it, and he got owned, had to reinstall the box. (And go track down the bozo advertising bad DNS in his DHCP.) It was ye olde DSO exploit. So someone installing (for whatever reason) something with IE5 can be taken over quite ruthlessly, especially since all you need do is show them an image.

Try Here

[Ieshan]

You could always check out the google Zeitgeist.

http://www.google.com/press/zeitgeist.html

Down in the middle of the page, it shows a graph that depicts MSIE 6.0 to be the dominant browser in nice clear red ink. :)

Re:Open Source More Secure... maybe not

[atallah]

Actually, 5.5 appears to be vulnerable. I loaded the BMP and BOOM! it crashed.

Re:Open Source More Secure... maybe not

[jimmyharris]

I would (and do) use the Fedora legacy project.

What version of RHL and FC will be supported, and for how long?

We are currently supporting Red Hat Linux 7.2, 7.3, and 8.0 as these have reached their End-of-Life (EOL).

When Red Hat Linux 9 becomes EOL on April, 31 2004, we will start legacy support for it as well.

As Fedora Core releases become EOL, we will provide support for them on a 1-2-3 and out policy, providing for roughly 1.5 years of update support for each release.

WARNING: ARTICLE CONTAINS SOURCE CODE

[Nailer]

This is completely off topic from the parent post. But THE LINKED ARTICLE CONTAINS SOURCE CODE FOR WINDOWS.

The Slashdot editors should remove the link immediately. Its really dangerous to have on the front page of this site.