Another Gaping Microsoft Security Hole Goes Unpatched

Newsbytes has a story about a critical vulnerability in all recent versions of Internet Explorer, which leaves your computer completely open any time you browse the web with IE. Microsoft has known about it since November 19; they refuse to provide any information about when a patch might be made available, if ever. This bug has been successfully handled by Microsoft's "Security through Obscurity" policies - since there's no public notice, Microsoft has no need to actually patch this hole which renders several hundred million computers vulnerable any time they access a web page or parse an HTML email.

For readers who care, this vulnerability results from Microsoft's integration of IE and the operating system. Files received via HTTP are supposed to be handled by examining the Content-Type header sent by the webserver - for instance, the Content-Type sent with this webpage is "text/html", identifying it as a text (non-binary) document which is marked up with HTML.

Netscape and most other browsers have no problem with this.

You will notice, however, that this method is rather different than how a Microsoft operating system determines how to handle a local file - by its three-letter extension. A file named "foo.txt" is handled as a text file, even if it is a binary image file that has been renamed for some reason.

Now, what happens when you integrate your web browser and your local browsing, say to render moot an anti-trust suit filed against your company? Will local files get a Content-Type? Will remote files be handled by examining their file extension?

IE handles files in an odd mish-mash of looking at the Content-Type sometimes for some purposes, looking at file extension sometimes for some purposes. It's hardly surprising that the bug-hunter in the above story has found a way to feed it a Content-Type at odds with the file extension - the Content-Type may be innocuous, but the extension says "execute me", so when the "integrated" IE engine gets ahold of it, the malicious content is automatically executed.

Now Microsoft has a problem. Because they chose to ignore the standard for handling downloaded files, Microsoft has painted themselves into a corner. If Microsoft suddenly changes how their browser handles downloaded files, tens of thousands (perhaps hundreds of thousands? any webpage which downloads files) of webpages "designed for IE" will have to be rewritten. No doubt this is the issue their programmers are wrestling with right now. It's a fundamental design issue - Microsoft designed their web browser with the goal of doing what was best for Microsoft (evading anti-trust charges) rather than doing what was best for their users. In fact a proper "fix" of this hole probably involves de-integrating their browser and local file handling to some extent.

If you routinely browse with Internet Explorer or read mail with Outlook, keep in mind that any web page you visit or any email you open can take over your computer, steal sensitive files, destroy your machine, anything. This has been true for at least two and half years. And keep in mind that you can't fix the problem, you must rely on Microsoft to do it, if they so choose. And keep in mind that Microsoft is in no hurry to do anything about it, because it doesn't even consider it a vulnerability. Happy browsing!

Comments

Re:hmm..

[aozilla]

The exploit is another one that allows a content type to be set that will cause executable code to download and execute without user intervention.

Hmm, did you read the story?

Any way to skip all dialogs, ie. to run an application without ANY dialog with this vulnerability has NOT been found. In all variations of the exploit there is always the normal file download dialog, but the following Security Warning dialog is skipped.

Re:Two and a half YEARS?

[J. J. Ramsey]

"If this bug in IE has really been around for two and a half years, how is it that no one has stumbled on to it until now?"

You are making the classic mistake of assuming that the first one to publicize the vulnerability is the first one to have found it. A malicious cracker could have known about the problem long before it was made public and exploited it silently.

That classic mistake is what is wrong with "security by obscurity." There is no guarantee that what is obscure to the general public is obscure to the bad guys.

Re:Saw this thread on bugtraq

[jamie]

The vulnerability was posted to Bugtraq on Nov. 26. One person tried to reproduce it the same day and failed. Its discoverer, Jouko Pynnonen, pointed out on bugtraq later the same day that:

Some details needed for reproducing and exploiting the flaw were left out of my posting because there is no good workaround or a patch available, and the flaw could be quite easily used maliciously. Using those details it would be relatively easy to create a worm that infects a system when a user "opens" a plain text file from an infected website, for instance. For the same reason there wasn't any test page URL included in my posting. That, and technical details will be published later.

Considering Microsoft's obstructionist response ("it's not a vulnerability, we'll fix it when we fix it, stop asking questions"), Jouko has been very kind not to publish any additional information about his discovery.

Nevertheless, other people tried to reproduce the exploit and succeeded. Jonathan G. Lampe posted on Nov. 29:

I have confirmed Jouko Pynnonen's and StatiC's findings that IE 5.5 sp 2 allows executables to run as soon as a user has elected to open what appears to be a normally harmless ".txt" file. (IE 5.5 trusts the filename provided in the link over the filename suggested by the header's filename tag and/or the use of an "application/octet-stream" content type.)

Here is the ASP equivalent code to StatiC's php tidbit...

I'd say the odds are pretty good that this is already being exploited in the wild.

There was some discussion of whether IE6 was vulnerable in the same way as IE5; the published exploit didn't seem to work on IE6. Jouko had originally commented that "Internet Explorer 6 is exploitable in a slightly different way, but the effect is the same."

HTTP is not synonymous with HTML!

[coyote-san]

The upstream comment is 100% pure bullshit.

When you're using Netscape or Lynx and the URL starts with "http:", it's speaking HTTP. It can use that protocol to send whatever type of data the server wants to send - text/html, application/x-pdf, whatever. You seem to be confusing HTTP and HTML - the communications protocol and what's being communicated.

Meanwhile, the canonical way to identify the type of a file on a Unix system is to look at for "magic numbers," and then hopefully verify them by parsing what you think is the header and making sure checksums are valid, values are sane, etc. Any Unix application developer that looks at the extension *alone* should usually be fired on the spot. (The sole exception is completely unstructured text where you have to use it as a hint, e.g., ".c" means C, ".cc" means C++.)

This isn't just a bad attitude, it reflects the fact that Unix tools have to deal with pipes and often don't have any filename (much less extension) associated with the data stream. If you require a file extension to understand what you have, you've crippled your application.

Check out NoHTML for Outlook

[lucidvein]

You should probably look into NoHTML by Russ Cooper of NTBugTraq.

"NoHTML.dll is an Outlook Add-in designed to convert HTML-based emails into harmless messages. It works slightly differently for Outlook 2000 than it does for Outlook 2002. Does not work with Outlook 98, or any version of Outlook Express."

Also a story about it here, http://www.theregister.co.uk/content/4/23223.html.

I've had it installed at work for a week now and do just fine without all the images and special formatting of spam.

Procmail Scanner

[ColaMan]

I have to plug something here.

Check out the procmail-based scanner at impsec.org

If you can set it up, do so - it's saved my ass quite a few times, by mangling active html content and renaming file extensions etc. It can also scan M$ docs for sus looking macros.

The following is something I received today that would slip through otherwise (notice the original content-type)

> SECURITY WARNING!
>
> The mail system has detected that the following
> attachment may contain hazardous program code, is
> a suspicious file type, or has a suspicious file name.
> Do not trust it. Contact your system administrator immediately.
>
> X-Content-Security: [www.ccimackay.com] original Content-Type was audio/x-wav;
> Content-Type: application/octet-stream; name="HUMOR.MP3.27525DEFANGED-scr"
> Content-Transfer-Encoding: base64
> Content-ID:
>

End of blatant plug :-)

Re:Intergating Web Browser and File Browser

[bnenning]

And with Apple's proposed adoption of file extensions as the standard filetype recogntion scheme, they'll be in the same boat as all the others anyway.

Any Mac OS X users interested in changing Apple's policies on file extensions should see the Mac OS X Metadata Petition. Yes, online petitions normally don't count for much, but John Siracusa has been very active in trying to get Apple to rethink this subject.