Last Comment Bug 439035 - Same-origin check in nsXMLHttpRequest::OnChannelRedirect() can be circumvented
: Same-origin check in nsXMLHttpRequest::OnChannelRedirect() can be circumvented
Status: VERIFIED FIXED
[sg:high xss]
: testcase, verified1.8.1.15, verified1.8.1.16
Product: Core
Classification: Components
Component: Security (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-13 01:54 PDT by moz_bug_r_a4
Modified: 2008-08-25 02:15 PDT (History)
12 users (show)
samuel.sidler+old: blocking1.8.1.15+
dveditz: blocking1.8.1.16+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix per above comments. (2.25 KB, patch)
2008-06-19 11:40 PDT, Johnny Stenback (:jst, jst@mozilla.com)
jonas: review+
jonas: superreview+
dveditz: approval1.8.1.15+
Details | Diff | Splinter Review

Description moz_bug_r_a4 2008-06-13 01:54:27 PDT
This is fx2-only.  (On trunk, the same-origin check in question compares an old
URI to a new URI.)

The same-origin check in nsXMLHttpRequest::OnChannelRedirect() uses a principal
of an associated JS context.  It can be circumvented by loading a cross-origin
page in that context before nsXMLHttpRequest::OnChannelRedirect() is called.

By using this trick, an attacker can read contents and http headers of a target
site.

Upcoming testcase consists of an html and a cgi script, thus it does not work
on bugzilla.mozilla.org.  Please set up it in a suitable place.
Comment 3 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-19 10:51:48 PDT
Jonas, any reason not to just make fx2 do what trunk does here? I.e. just compare the URIs and not bother using the unreliable context pointer here?
Comment 4 Jonas Sicking (:sicking) PTO Until July 5th 2008-06-19 11:12:24 PDT
Yup, that's what we should do
Comment 5 Mike Schroepfer 2008-06-19 11:38:36 PDT
Jonas can you work up the patch?
Comment 6 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-19 11:40:24 PDT
Created attachment 325799 [details] [diff] [review]
Fix per above comments.

This fixes this bug, verified with local install of the testcase.
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-19 15:19:13 PDT
Comment on attachment 325799 [details] [diff] [review]
Fix per above comments.

Not sure if we've decided to take more changes for 1.8.1.15, but if we did this would be a good candidate.
Comment 8 Daniel Veditz [:dveditz] 2008-06-20 11:23:01 PDT
Comment on attachment 325799 [details] [diff] [review]
Fix per above comments.

Approved for 1.8.1.15 and 1.8.1.16, a=dveditz for release-drivers

Please land on both branches (MOZILLA_1_8_BRANCH for 1.8.1.16 and GECKO181_20080612_RELBRANCH for 1.8.1.15) and give the bug both fixed1.8.1.15 and fixed1.8.1.16 keywords
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-20 13:42:02 PDT
Fix landed on both branches.
Comment 10 Al Billings [:abillings] 2008-06-23 11:41:55 PDT
Verified the bug with Firefox 2.0.0.14 and the fix with the final 2.0.0.15 build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15) Gecko/2008062305 Firefox/2.0.0.15).
Comment 14 Al Billings [:abillings] 2008-07-02 16:00:24 PDT
I've verified this, again, with : Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/2008070205 Firefox/2.0.0.16. With 2.0.0.14, I get the data from mozilla.com in great detail. This does not happen in 2.0.0.16.
Comment 16 Samuel Sidler (old account; do not CC) 2008-08-25 02:15:46 PDT
Comment on attachment 325799 [details] [diff] [review]
Fix per above comments.

This patch had approval for 1.8.1.16, but apparently the flags got moved out. Clearing that flag to clear the queries.

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