You're not very detailed about what happens behind the curtain, so here
goes :)
When an HTTP request returns its data, IE tries to determine the MIME
type based on several factors [0]. In this case, IE determines that it
cannot render the data as HTML since there is a Content-Disposition
header - Content-Disposition is used whenever you e.g. output a binary
file from a serverside script and want the filename to be displayed as
"ProjectScope.doc" instead of "download.php" (your scripts name).
The Content-Disposition HTTP header itself is not to blame, it is a
standard MIME header from RFC 1806 that has been widely implemented in
all browsers precisely to allow arbitrary filenaming.
Since IE cannot display the data itself, it displays the Open/SaveAs
dialog box so that the user can decide. The %2E in the filename is URL
decoded and displayed as a . (dot) in the dialog. This URL decoding
should simply not be performed as we are dealing with a file dialog and
not a URL dialog, if %2E had not been decoded we would not be having
this issue.
Whatever action the user takes is then handled by Windows Explorer, we
are now no longer dealing with IE. Windows Explorer determines what
application to open the data with based on lesser rules than Internet
Explorer, for one it does not look at the Content-Type header since it
does not know about it. The first step of action is to compare the file
extensions, only in the case of an unknown file extension does Windows
Explorer perform its "magic filetype" guessing by inspecting the files
content.
The file extension in Windows is no longer limited to 3 characters,
though historical reasons have kept most application extensions confined
to these. Windows Explorer parses the filename, excluding its path, and
determines that the file extension is everything following the last .
(dot) character, in this case ".{GUID}%2Efunny.mpeg". Common extensions
are either a set of printable characters or a GUID, with the latter
having priority over the former. After this, a lookup is performed in
the registry for HKCR\CLSID\.GUID and HKCR\.EXT, with EXT being the file
extension that we discovered and GUID the CLSID we found, and a match is
found for the GUID prior to the entire file extension. The GUID points
at "HTML Application" which points at MSHTA.EXE, which is then used to
display the data.
As with the ".Folder" issue, this definitely eases social engineering.
Internet Explorer should not URL decode strings for file dialogs and
Windows Explorer should not give precedence to CLSID's.
[0]
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_
a.asp
Regards
Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thor@pivx.com
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569
PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of
Qwik-Fix
<http://www.qwik-fix.net>
-----Original Message-----
From: http-equiv@excite.com [mailto:1@malware.com]
Sent: Tuesday, January 27, 2004 9:27 AM
To: bugtraq@securityfocus.com
Cc: NTBugtraq@listserv.ntbugtraq.com
Subject: GOOROO CROSSING: File Spoofing Internet Explorer 6
Tuesday, January 27, 2004
Trivial file spoofing in Internet Explorer 6.0.2800.1106 and all
of 'its' patches to date on WIN XP [probably others]:
Content-Disposition: attachment; filename=malware.{3050f4d8-98B5-
11CF-BB82-00AA00BDCE0B}fun_ball_gites_pie_throw%2Empeg"
Absolute bare minimum working demo [perhaps even feeble] as we
are absolutely confident the self-appointed resident gooroo will
be along shortly handing out packets of two cents to everyone
thus saving us the effort to illustrate in even greater detail
to those lacking imagination:
http://www.malware.com/gooroo.html
End Call
--
http://www.malware.com
