Closed Bug 387333 Opened 17 years ago Closed 17 years ago

[FIX]unauthorized access to wyciwyg:// documents possible

Categories

(Core :: Security, defect, P1)

1.8 Branch
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: lcamtuf, Assigned: bzbarsky)

References

()

Details

(Keywords: fixed1.8.0.13, verified1.8.1.5, Whiteboard: [sg:high])

Attachments

(1 file)

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.
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
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?
Flags: blocking1.8.1.6?
Flags: blocking1.8.1.5?
Whiteboard: [sg:low]
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.
Assignee: nobody → dveditz
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox → toolkit
Version: 2.0 Branch → 1.8 Branch
Attached patch Like soSplinter Review
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.
Attachment #271479 - Flags: superreview?(jst)
Attachment #271479 - Flags: review?(dveditz)
Assignee: dveditz → bzbarsky
Priority: -- → P1
Summary: unauthorized access to wyciwyg:// documents possible → [FIX]unauthorized access to wyciwyg:// documents possible
Attachment #271479 - Flags: approval1.8.1.5?
Attachment #271479 - Flags: approval1.8.0.13?
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.
Yeah, I could reproduce this on branch.  And I get the expected security error with the patch.
(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").
(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
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.6?
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
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
Attachment #271479 - Flags: review?(dveditz)
Attachment #271479 - Flags: review+
Attachment #271479 - Flags: approval1.8.1.5?
Attachment #271479 - Flags: approval1.8.1.5+
Attachment #271479 - Flags: approval1.8.0.13?
Attachment #271479 - Flags: approval1.8.0.13+
Attachment #271479 - Flags: superreview?(jst) → superreview+
Fixed on both branches.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
"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')
Whiteboard: [sg:low] → [sg:high]
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
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.