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

VERIFIED FIXED

Status

()

Core
Security
P1
normal
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: Michal Zalewski, Assigned: bz)

Tracking

({fixed1.8.0.13, verified1.8.1.5})

1.8 Branch
fixed1.8.0.13, verified1.8.1.5
Points:
---
Bug Flags:
blocking1.8.1.5 +
wanted1.8.1.x +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high], URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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

10 years ago
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
Component: Security → Security
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox → toolkit
Version: 2.0 Branch → 1.8 Branch
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.
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?
(Reporter)

Comment 5

10 years ago
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").
(Reporter)

Comment 8

10 years ago
(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+

Updated

10 years ago
Attachment #271479 - Flags: superreview?(jst) → superreview+
Fixed on both branches.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.8.0.13, fixed1.8.1.5
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]

Comment 12

10 years ago
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

10 years ago
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
Keywords: fixed1.8.1.5 → verified1.8.1.5
You need to log in before you can comment on or make changes to this bug.