Closed Bug 495270 Opened 16 years ago Closed 13 years ago

It's possible to spoof SSL UI (but not possible to spoof URI)

Categories

(Core :: Security, defect)

1.8 Branch
defect
Not set
major

Tracking

()

RESOLVED WONTFIX

People

(Reporter: samuel.sidler+old, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [sg:moderate spoof])

+++ This bug was initially created as a clone of Bug #482206 +++ Morphing out the 1.8 bug from bug 482206 comment 19 and on. I think because the testcase isn't as bad on 1.8, this is sg:low not sg:high... > Created attachment 370801 [details] > screenshot > > Hmm, 1.8 branch is not safe. On 1.8 branch, by using the same testcase, it's > possible to spoof SSL UI (but not possible to spoof URI). > The 1.8 behavior might be some other bug entirely, but until we know that we'll > block on fixing this testcase. > (In reply to comment #19) > > Hmm, 1.8 branch is not safe. On 1.8 branch, by using the same testcase, it's > > possible to spoof SSL UI (but not possible to spoof URI). > > moz_bug, I tried to reproduce this with my own 1.8 branch build and also with > official 2.0.0.20 release and couldn't get firefox into this spoofed state; any > hints how you set up the test for this screenshot? > Created attachment 374838 [details] > testcase 2 > > I can reproduce the first testcase with 1.8 on Windows, but not on Linux. I > can reproduce this modified testcase with 1.8 on Linux. Please try this.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.next+
Whiteboard: [sg:moderate spoof]
13:32 <@bz> ss: so my estimate is that fixing it is probably a few days of work 13:32 <@bz> ss: most of that trying to figure out which assumptions have to differ between 1.8 and 1.9 13:32 <@bz> ss: my initial gut feeling is that we should just bail on fixing this on 1.8... 13:32 <@bz> ss: and that if someone feels really strongly about that, they should put in the time to do it 13:33 <@bz> ss: just backporting the patch in the bug will almost certainly break web sites, fwiw
So the issue is that we're getting the security state from the document but the principal off the stack. We could consider getting the principal off the document (which is what the fixes in bug 482206 did), but then we need to make sure that the about:blank principal changes landed on branch (did they?) and that there are no other issues with that approach. Some serious code auditing is probably needed. The failure mode here would be giving the wrong principal to the result document and then script breaking when it tries to access it, I think. I don't think privilege escalation would be possible. We could also consider getting the security infon only if the principal matches that of the document. This could still cause issues in the cases where the "get the principal off the document" behavior would have issues, but the failure mode would be not having SSL UI when we should. I'll be honest: I don't have the time in the near future to sort out all the details above and figure out what the right behavior for branch is. Someone who cares about the branch releases should step up here.
Reflecting reality...
Assignee: bzbarsky → nobody
The 1.8 branch is no longer a supported branch, marking this WONTFIX.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Group: core-security
You need to log in before you can comment on or make changes to this bug.