Last Comment Bug 387333 - [FIX]unauthorized access to wyciwyg:// documents possible
: [FIX]unauthorized access to wyciwyg:// documents possible
Status: VERIFIED FIXED
[sg:high]
: fixed1.8.0.13, verified1.8.1.5
Product: Core
Classification: Components
Component: Security (show other bugs)
: 1.8 Branch
: All All
: P1 normal with 1 vote (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
http://lcamtuf.coredump.cx/ffcache/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-08 14:31 PDT by Michal Zalewski
Modified: 2010-10-27 02:23 PDT (History)
12 users (show)
dveditz: blocking1.8.1.5+
dveditz: wanted1.8.1.x+
dveditz: wanted1.8.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Like so (1.26 KB, patch)
2007-07-08 19:07 PDT, Boris Zbarsky [:bz] (Out June 25-July 6)
dveditz: review+
jst: superreview+
dveditz: approval1.8.1.5+
dveditz: approval1.8.0.13+
Details | Diff | Review

Description Michal Zalewski 2007-07-08 14:31:52 PDT
It is possible to access wyciwyg:// documents without proper same domain policy checks through the use of HTTP 302 redirects, as demonstrated here:

http://lcamtuf.coredump.cx/ffcache/

This enables the attacker to: steal sensitive data displayed on dynamically generated pages; perform cache poisoning; and execute own code or display own content with URL bar and SSL certificate data of the attacked page (URL spoofing++).

PS. It is also possible to access wyciwyg:// through XMLHttpRequest and IFRAMEd view-source:. Although proper access control seems to be more or less exercised, this seems to be not the intended effect, judging from comments in existing code; and the mechanism can be used by rogue sites to conveniently tag visitors regardless of cookie restrictions (write a unique ID  to a wyciwyg:// file with document.write(), then do XMLHttpRequest on returning visitors), so you might want to tighten it.
Comment 1 Jo Hermans 2007-07-08 16:32:52 PDT
In Minefield (latest trunk), I get :
"Something went wrong - my redirection trick didn't work.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre
Comment 2 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-08 17:01:21 PDT
I get the "trick didn't work" dialog with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070701 BonEcho/2.0.0.5pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre

Is there something wrong with the testcase?
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-08 18:20:05 PDT
Hmm.  On trunk this won't work; any place that actually does security checks (and that should be all of them, of course) won't allow wyciwyg loads.

We should probably fix this on branch.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-08 19:07:19 PDT
Created attachment 271479 [details] [diff] [review]
Like so

As far as I can tell, with this patch we can still go back to document.written pages, so history loads work as they should.
Comment 5 Michal Zalewski 2007-07-09 00:30:38 PDT
Gavin, no clue about trunk (Boris is probably right). Boris, I take you could reproduce this on branch?

If you have problems, make sure you visited the "beaver bank" site and clicked "login"; if you did, the only thing to check is whether a wyciwyg://0/http://beaverbank.dione.cc/ document got created (say, view -> page source, then see the title bar of the viewer window). 

"Trick didn't work" error (and a "page moved" pop-up window) simply means that HTTP 302 Redirect to Location: wyciwyg://0/http://beaverbank.dione.cc/ did not go as planned.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-09 01:05:27 PDT
Yeah, I could reproduce this on branch.  And I get the expected security error with the patch.
Comment 7 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-09 05:32:41 PDT
(In reply to comment #5)
> If you have problems, make sure you visited the "beaver bank" site and clicked
> "login"; if you did, the only thing to check is whether a
> wyciwyg://0/http://beaverbank.dione.cc/ document got created (say, view -> page
> source, then see the title bar of the viewer window).

I did visit the "beaver bank" site, and I did click login. The URI I saw when viewing the page's source was of the form "wyciwyg://0/http://beaverbank.dione.cc/", but the "0" was "19", and increased to "20" when I cleared my cache and tried to reproduce again. That explains why your testcase isn't working for me, I guess (it seems to assume the URL will contain "0").
Comment 8 Michal Zalewski 2007-07-09 05:47:39 PDT
(In reply to comment #7)
> it seems to assume the URL will contain "0"

Yup; it usually does, but if not, could be quickly brute-forced by an exploit.

/mz
Comment 9 Daniel Veditz [:dveditz] 2007-07-09 10:45:22 PDT
Comment on attachment 271479 [details] [diff] [review]
Like so

r=dveditz
approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-09 16:35:41 PDT
Fixed on both branches.
Comment 11 Daniel Veditz [:dveditz] 2007-07-10 12:20:06 PDT
"stealing sensitive data" should be sg:high (possibly lowered to sg:moderate if it's a completely unreliable attack, involves unlikely user interaction, or not really any potential victim sites matching the criteria. There are enough ajaxy sites potentially vulnerable to stick with 'high')
Comment 12 Andrew Shadura 2007-07-10 13:24:46 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 - Build ID: 2007051502
bug doesn't work
Comment 13 Adam Guthrie 2007-07-10 13:58:52 PDT
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070710 BonEcho/2.0.0.5pre.

In a build from 2007-07-09 without the patch, the content gets injected and the attack is successful, but with the above build, the attack fails and I get the security error Boris mentioned.

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