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:You thought Microsoft were tardy with

[LostCluster]

There apparently is already a fix for this one installed on many machines. It's called IE6.

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:Text of advisory

[AstroDrabb]

I actaully read that in the EULA for MS Front Page you are not allowed to use Front Page to make any site that is demeaning to microsoft, and by using MS Front Page, you agree to not make any negative sites about MS.

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:huh

[MindStalker]

The guy sent mail to securityfocus telling them that there was a hole in windows, he did not spread any virus or use this code malisously. SecurityFocus then published this info, if anyone SecurityFocus is the most liable, though I don't believe either should be.

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:Source code leak == reason for Palladium/TCP?

[thebatlab]

Come on, who keeps modding this stuff as insightful? It's been beaten to death. Personally I don't agree with the conspiracy theory but that's irrelevant. This was mentioned many times in the first article

http://slashdot.org/comments.pl?sid=96614&cid=8268 186
http://slashdot.org/comments.pl?sid=96614&cid=8266 149
http://slashdot.org/comments.pl?sid=96614&cid=8267 608
http://slashdot.org/comments.pl?sid=96614&cid=8266 723
http://slashdot.org/comments.pl?sid=96614&cid=8262 805

and the follow-up article

http://slashdot.org/comments.pl?sid=96732&cid=8271 595
http://slashdot.org/comments.pl?sid=96732&cid=8270 866
http://slashdot.org/comments.pl?sid=96732&cid=8270 862

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.

Re:I posted that vulnerability on August 13, 2000

[Durin_Deathless]

Fair enough. In the future, how about a link to the comment like this?

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.

Bittorrent Links Includeded

[Anonymous Coward]

Win NT 4.0 Source:
http://torrent.spyderlake.com/download.php?info_ha sh=66a26447f563c3dc2336de74ae37dc14d11dd8b9

Win 2000 Source:
http://torrent.spyderlake.com/download.php?info_ha sh=f03fc1e04869294d5644d3c8c5d0fb8f2d26aa59

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.

Re:Free as in beer helps as well

[GlassHeart]

I think the point is that you can patch Red Hat 5.x for free by upgrading to a more recent version of Red^H^H^HFedora for no charge.

Please read the original post I was responding to, which states:

Unless your arguing that staying current is the only way to avoid exploits, then your making a strong argument that the TCO of Open Source should be sung from the moutain top.

I'm not going to respond to each response with the same message, so here it is:

The IE situation is the worst. You probably have no choice but to upgrade. In this case you can probably download IE 6 for free, but for other exploits you may have to pay for a newer version of Windows. Hear me, it's the worst.

The open source situation is better. You at least have the source, and at the worst case can go patch it yourself or pay somebody to patch it. Some investment in time or money can enable you to stay with an older version to avoid upgrading.

However, open source doesn't solve all the problems. If there's no volunteer to keep an old version patched, then there's some cost on your part if you don't want to upgrade. Upgrading, on the other hand, contains some risks (which may translate to cost as well). For one, the new features may contain new exploits.

Which is why I wrote that insisting on running Red Hat 5.0 may be expensive, even though it's open source. It's entirely possible (which is good, and better than IE or Windows), because you have source, but it may not be viable, despite having the source.

Somebody brought up Debian. Yes, Debian maintains an excellent stable distribution. However, not even Debian volunteers patch every old version. At some point, "testing" becomes "stable" and the old "stable" will be left to rot. If you insist on running the old one, then your personal TCO will increase significantly.

And now the obvious conclusion: not even open source can make not upgrading a viable option forever. At some point (obviously at different points for Windows compared to Red Hat Linux) it's cheaper to upgrade. That's all I'm saying.

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.