Last Comment Bug 187996 - Strange behavior on 305 redirect
: Strange behavior on 305 redirect
: testcase
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: x86 Windows 2000
-- normal (vote)
: mozilla1.3beta
Assigned To: Darin Fisher
: benc
: Patrick McManus [:mcmanus]
Depends on:
  Show dependency treegraph
Reported: 2003-01-06 18:22 PST by Mitchell Stoltz (not reading bugmail)
Modified: 2011-12-30 10:18 PST (History)
11 users (show)
asa: blocking1.3b+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

v1 patch: fixes SOCKS fu (842 bytes, patch)
2003-01-06 18:28 PST, Darin Fisher
no flags Details | Diff | Splinter Review
Mini web server in perl to demonstrate reading pages behind fwl (1.03 KB, text/plain)
2003-01-09 03:04 PST, georgi - hopefully not receiving bugspam
no flags Details
v2 patch (6.94 KB, patch)
2003-01-27 16:34 PST, Darin Fisher
no flags Details | Diff | Splinter Review
v2 patch (w/ whitespace removed) (1.79 KB, patch)
2003-01-27 16:36 PST, Darin Fisher
bbaetz: review+
bzbarsky: superreview+
dbaron: approval1.3b+
Details | Diff | Splinter Review

Description User image Mitchell Stoltz (not reading bugmail) 2003-01-06 18:22:27 PST

The HTTP response 305 "Use cache is dangerous".
Check attached file
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:
/ | nc -l -p 1234 
(to send raw http on port 1234)
3. In mozilla:

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.

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

print "HTTP/1.1 305 Use proxy\n";
#print "Location:\n";
print "Location: localhost:25\n";
#print "Content-Location: http://localhost:2345\n";
#print "Content-Location:\n";
#print "Refresh: 2; URL=http://localhost\n";
print "\n\n";
Comment 1 User image Mitchell Stoltz (not reading bugmail) 2003-01-06 18:23:24 PST
Georgi, I'm not clear on what the potential exploit is - what's at stake here?
Comment 2 User image Darin Fisher 2003-01-06 18:27:11 PST
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 User image Darin Fisher 2003-01-06 18:28:51 PST
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.
Comment 4 User image georgi - hopefully not receiving bugspam 2003-01-07 03:44:21 PST
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 User image Darin Fisher 2003-01-08 23:30:08 PST
the temporary proxy only applies to the current URL.  if the current URL is, then only cookies from 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 User image Darin Fisher 2003-01-08 23:33:21 PST
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 User image Bradley Baetz (:bbaetz) 2003-01-09 00:28:54 PST
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 User image Darin Fisher 2003-01-09 00:35:58 PST
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 User image Darin Fisher 2003-01-09 00:37:21 PST
the 305 regression was caused by my patch for bug 105340 :(
Comment 10 User image Bradley Baetz (:bbaetz) 2003-01-09 01:05:49 PST
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 User image georgi - hopefully not receiving bugspam 2003-01-09 02:22:03 PST
For comment #10:
Bradley, this works also with http/1.1 on default install of apache (at least
apache happily server full urls. Works even on Probably this means
that pages from the intranet may be retrieved. 
To check:
In from the description change
Location: localhost:25\n

Or if one doesn't have netcat (aka nc)
here is a standalone perl proggie:
# Written by Georgi Guninski
use IO::Socket;

#local port
$port = 1234;

#redirect to

$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...";
#	while(<$client>) {print $_;} 
 print $client "$msg";
 print "OK\n";


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

Comment 12 User image georgi - hopefully not receiving bugspam 2003-01-09 03:04:04 PST
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 is displayed in an alert.
Comment 13 User image georgi - hopefully not receiving bugspam 2003-01-09 03:32:16 PST
The whole purpose of 305 as described in the rfc seems brain damaged to me from
security point of view.
Comment 14 User image Darin Fisher 2003-01-13 13:46:42 PST
i agree.  i wonder if we shouldn't consider dropping support for 305.
Comment 15 User image Darin Fisher 2003-01-13 13:50:26 PST
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 User image Bradley Baetz (:bbaetz) 2003-01-14 01:52:01 PST
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 User image georgi - hopefully not receiving bugspam 2003-01-14 02:03:11 PST
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 User image georgi - hopefully not receiving bugspam 2003-01-16 06:31:14 PST
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 User image Darin Fisher 2003-01-16 16:53:41 PST
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 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-16 20:45:27 PST
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 User image georgi - hopefully not receiving bugspam 2003-01-17 01:12:54 PST
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>""); //target
//...wait till it is loaded...
a.location.href="http://malicous/something"; // malicous returns 204 response

Comment 22 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-17 08:54:35 PST
Yeah, I don't think we follow the rfc there.  We basically pretend the request
never existed if we get a 204.
Comment 23 User image georgi - hopefully not receiving bugspam 2003-01-17 09:11:34 PST
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 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-17 11:41:23 PST
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 User image Bradley Baetz (:bbaetz) 2003-01-18 01:13:13 PST
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 User image Darin Fisher 2003-01-27 16:34:58 PST
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.
Comment 27 User image Darin Fisher 2003-01-27 16:36:40 PST
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 28 User image Bradley Baetz (:bbaetz) 2003-01-27 23:23:46 PST
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 User image Darin Fisher 2003-01-28 10:16:21 PST
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 User image Darin Fisher 2003-01-28 10:23:20 PST
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:

  echo 'status: 305 use proxy'
  echo 'location:'
  echo ''
  echo 'use proxy!'

with this patch, the user should see "use proxy!" displayed in the browser window.
Comment 31 User image Darin Fisher 2003-01-28 17:14:53 PST
Comment 32 User image benc 2003-02-07 10:10:01 PST
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 User image bmartin 2003-02-10 16:48:19 PST
Testing against latest branch 2002-02-10-09 on Win2000

1. At command prompt, run attached test files or (these
scripts listen on localhost:1234 and will try to redirect to
2. Launch branch build and go to http://localhost:1234

Mozilla will not load or display within the browser.
Comment 34 User image bmartin 2003-02-12 14:29:49 PST
Marking this Verified Fixed on the Branch based on my previous comment.

Note You need to log in before you can comment on or make changes to this bug.