Summon comment box
From guninski@guninski.com: 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";
Georgi, I'm not clear on what the potential exploit is - what's at stake here?
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.
Created attachment 110838 [details] [diff] [review] 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.
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?
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.
incidentally RFC 2616 doesn't say anything about whether or not a POST should be resent to the proxy server. perhaps it should.
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?
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.
the 305 regression was caused by my patch for bug 105340 :(
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.
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.
Created attachment 111033 [details] 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.
The whole purpose of 305 as described in the rfc seems brain damaged to me from security point of view.
i agree. i wonder if we shouldn't consider dropping support for 305.
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.
Yeah. Lets just #ifdef it out, or something. I remmeber when doing the proxy rewrite that I was surprised that we suppoted it
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.
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.
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.
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.
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>
Yeah, I don't think we follow the rfc there. We basically pretend the request never existed if we get a 204.
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.
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...
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...
Created attachment 112823 [details] [diff] [review] 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.
Created attachment 112824 [details] [diff] [review] v2 patch (w/ whitespace removed) same patch w/ whitespace removed. (v1 patch was accidentally included in async-io landing.)
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 on attachment 112824 [details] [diff] [review] v2 patch (w/ whitespace removed) requesting approval to checkin this patch for 1.3 beta. simple code removal.
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.
fixed-on-trunk
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.
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.
Marking this Verified Fixed on the Branch based on my previous comment.
or
