Re: File extensions spoofable in MSIE download dialog

From: Georgi Guninski (guninski@guninski.com)
Date: 11/26/01


Message-ID: <3C027A38.77715ECF@guninski.com>
Date: Mon, 26 Nov 2001 19:22:00 +0200
From: Georgi Guninski <guninski@guninski.com>
To: Jouko Pynnonen <jouko@solutions.fi>
Subject: Re: File extensions spoofable in MSIE download dialog

I don't have internet explorer to test but rfc 2616 describes some "security considerations".
It is a good idea browser vendors check this:
--------------------------------------------------------
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5
[15 Security Considerations]
15.5 Content-Disposition Issues

RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.
---------------------------------------------------------

Georgi Guninski
http://www.guninski.com

Jouko Pynnonen wrote:
>
> OVERVIEW
>
> A flaw in Microsoft Internet Explorer allows a malicious website to spoof
> file extensions in the download dialog to make an executable program file
> look like a text, image, audio, or any other file. If the user chooses to
> open the file from its current location, the executable program will be
> run, circumventing Security Warning dialogs, and the attacker could gain
> control over the user's system.
>
> A piece of HTML can be used to cause a normal download dialog to pop up.
> The dialog would prompt the user to choose whether he/she wants to "open
> this file from its current location" or "save this file to disk". The
> file name and extension may be anything the malicious website
> administrator (or a user having access there) wishes, e.g. README.TXT,
> index.html, or sample.wav. If the user chooses the first alternative,
> "open the file from its current location", an .EXE application is
> actually run without any further dialogs. This happens even if
> downloading a normal .EXE file from the server causes a Security Warning
> dialog.
>
> The user has no way of detecting that the file is really an .EXE
> program and not a text, html, or other harmless file. The program could
> quietly backdoor or infect the user's system, and then pop up a window
> which does what the user expected, ie. show a text document or
> play an audio file.
>
> No active scripting is necessary in order to exploit the flaw. The
> malicious website can be refered e.g. in an iframe, in a normal link, or
> by javascript.
>
> DETAILS
>
> The flaw is in the way Internet Explorer processes certain kind of URLs
> and HTTP headers. No further technical details are disclosed this time,
> as there is no proper workaround and the vulnerability could be
> relatively easily and unnoticeably exploited to spread virii, install
> DDoS zombies or backdoors, format harddisks, and so on.
>
> The flaw has been successfully exploited with Internet Explorer 5.5 and
> 6. An IE5 with the latest updates shows the spoofed file name and
> extension without a sign of EXE, and issue no Security Warning dialog
> after the file download dialog.
>
> Internet Explorer 6 is exploitable in a slightly different way, but the
> effect is the same. The user gets a download dialog with the spoofed file
> name and extension, and can choose between "Open" and "Save". Opening the
> file causes the program to be run.
>
> Older versions such as IE5.0 behave somewhat differently. The dialog
> indicates the user is about to execute an application; the dialog has the
> word "execute" instead of "open", and a Security Warning dialog appears
> after choosing "execute". It still shows the spoofed file name and
> extension instead of "EXE".
>
> 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.
>
> Technical details of the vulnerability will be revealed later.
>
> WORKAROUNDS
>
> Opening a file type previously considered safe, e.g. plain text or HTML
> file isn't safe with IE. Users of the browser should avoid opening
> files directly and save them to disk instead (if opening them is
> necessary at all). If this flaw is being exploited, the file save dialog
> will reveal that the file is actually an executable program. Dealing with
> files from an untrusted source isn't advisable anyway. Another workaround
> is switching to another browser such as Opera or Netscape which don't
> seem to have this vulnerability.
>
> VENDOR STATUS
>
> Microsoft was contacted on November 19th. The company doesn't currently
> consider this is a vulnerability; they say that the trust decision should
> be based on the file source and not type. The origin of the file, ie. the
> web server's hostname can't be spoofed with this flaw. It's not known
> whether a patch is going to be produced. Microsoft is currently
> investigating the issue.
>
> --
> Jouko Pynnonen Online Solutions Ltd Secure your Linux -
> jouko@solutions.fi http://www.solutions.fi http://www.secmod.com