302489 - XMLHTTP TRACE method can reveal proxy passwords to web sites

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Yutaka OIWA]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Proxy authentication passwords are stolen by malicious Javascript.

In addition, the web authentication passwords for any pages on the 
same web servers (including ones for other people's web contents)
can also be stolen.


Reproducible: Always

Steps to Reproduce:
Let victims execute the following Javascript.

 xmlhttp = new XMLHttpRequest();
 xmlhttp.open("TRACE", "a.html");
 xmlhttp.setRequestHeader("Max-Forwards", "0");
 xmlhttp.onreadystatechange=function() {
 if (xmlhttp.readyState==4) {
  alert("Status: " + xmlhttp.status + "\n" + xmlhttp.responseText)
 }
 }
 xmlhttp.send(null)
}


Expected Results:  
TRACE request should be banned, at least for scripts.

Splitted from bug 297078 after successed constructing an exploit.

If plugins are allowed to use Mozilla's internal HTTP layer,
there may be a similar problem. Please check them, too.

Comment 1

[Darin Fisher]

Over to the XML component.

Do flash or java provide ways to issue TRACE requests?  If so, wouldn't that be
a bug with those plugins?  I believe that our plugin API gives plugins the
ability to issue HTTP requests using our stack, but a plugin could easily use
its own HTTP stack, so limiting what a plugin can do wouldn't be worth it.

Comment 2

[Yutaka OIWA]

(In reply to comment #1)
> Over to the XML component.
> 
> Do flash or java provide ways to issue TRACE requests?

I do not know.  I'm not a specialist in either Mozilla or those plugins.

> If so, wouldn't that be
> a bug with those plugins?  I believe that our plugin API gives plugins the
> ability to issue HTTP requests using our stack, but a plugin could easily use
> its own HTTP stack, so limiting what a plugin can do wouldn't be worth it.

I believe the opposite. Using browser's HTTP stack gives
more power than using its own HTTP stack: depending on the browser's
implementation, it may use secret credential stored in the browser,
or it may share the keep-alive connections and proxy connections 
with other browser-initiated request(*1).  This cannot be achieved by
plugin's own HTTP implementation.  The reported problem does not arise
for any components which uses its own HTTP implementation, unless
users told the same secret explicitly to such components.

So, allowing its HTTP stack for other's use should be careful in general.
Having an interface which allows arbitrary requests to be sent is equivalent
to having an interface which allows every secret passwords to be read by them.
Having own "sanity check" before using own secret credential will be a good,
"more secure" idea.

(*1) If Mozilla differentiate between internally/externally generated request
     and do not perform such a thing for external requests, it is no problem.
     I don't know about such internal issue.

Comment 3

[Darin Fisher]

You make a good point about re-using the same HTTP stack.  It is indeed the case
that Mozilla does not differentiate external vs internal HTTP requests, so they
would all potentially be pipelined together, for example.  But, plugins do
actually have access to Mozilla's password cache.  There is an API for that
explicitly to allow the Java plugin to act like it is using Mozilla's HTTP stack
when in fact it is not.

Comment 4

[Yutaka OIWA]

(In reply to comment #3)
> But, plugins do
> actually have access to Mozilla's password cache.  There is an API for that
> explicitly to allow the Java plugin to act like it is using Mozilla's HTTP stack
> when in fact it is not.

Oops...  Is it a good design?  I might become wanting to send a
featurewish bug report about changing this interface :-P

# Is there a API for getting cookies, too?

Anyway, this answers to my first concern, in very unexpected way :-)
Now this is not the issue for plugin (modulo cookies), I agree.
Fixing it at XMLHTTP layer will be fine.

# How about issues in bug 302263? Does the problems regarding
# Content-length and Transfer-encoding reappear for plugins?
## Host might not be a problem in this case.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

there is an API for cookies too, yes. Additionally, plugins _can_ use mozilla's
networking stack if they so desire.

Comment 6

[Yutaka OIWA]

(In reply to comment #5)
> there is an API for cookies too, yes. Additionally, plugins _can_ use mozilla's
> networking stack if they so desire.

OK.

Self Addition to #4:
I feel that possible plugin-based request-splitting issue
(which I have written in #4) is less critical (at least) now.
(Because there are no known vulnerable plugins)
Please keep it aside now.
# Does someone know whether Macromedia flash has an ability to
# pass arbitrary-chosen HTTP headers to Mozilla?

Comment 7

[Darin Fisher]

Attachment: v1 patch

Comment 8

[Daniel Veditz [:dveditz]]

The standard plugin API only supports Get and post. The plugin could make it's
own raw calls of course, but not using our networking engine.

We added scriptability to plugins, but that should be sandboxed to the
containing web page and again not allow raw access to the network engine.

Java has a special OJI interface with more stuff exposed, but applets shouldn't
have raw access to anything.

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 190884 [details] [diff] [review]
v1 patch

sr=dveditz

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #8)
> The standard plugin API only supports Get and post. The plugin could make it's
> own raw calls of course, but not using our networking engine.

plugins can get the service manager
(http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/public/npapi.h#419)
and from that the necko services. plugins can use mozilla's networking engine
just fine.

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to comment #10)
> plugins can get the service manager [...] and from that the necko services.
> plugins can use mozilla's networking engine just fine.

True, but then they've stepped outside the NPAPI into functionality that won't
work on other browsers like Opera or Safari so there's a fair incentive not to
do that. And a plugin author would be insane if they passed that raw ability
through to the media content. If they allow content to send TRACE they've gone
out of their way to do so, it's their flaw.

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 190884 [details] [diff] [review]
v1 patch

r=jst

Comment 13

[Darin Fisher]

fixed-on-trunk

Comment 14

[chris hofmann]

a bunch of test cases dumped into
https://bugzilla.mozilla.org/show_bug.cgi?id=297078

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 190884 [details] [diff] [review]
v1 patch

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.

Comment 16

[Darin Fisher]

fixed-aviary1.0.8, fixed1.7.13

Comment 17

[Bob Clary [:bc] (inactive)]

I did test this and it passed on ff 1.0.8 on all platforms.

example:

mfTest: bug 302489: Test https://bugzilla.mozilla.org/show_bug.cgi?id=302489: XMLHTTP TRACE method can reveal proxy passwords to web sites Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060221 Firefox/1.5 Passed. (Pass: 1, Fail: 0)
mfTest: bug 302489: ASSERT: Passed : XMLHttpRequest prevented from sending TRACE requests
mfTest: bug 302489: INFORM: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: http://test.mozilla.com/tests/mozilla.org/security/302489-01.html :: test :: line 69" data: no]