Closed Bug 928187 (CVE-2016-5283) Opened 11 years ago Closed 8 years ago

<iframe src> fragment timing attack can reveal private data

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox47 + wontfix
firefox48 --- wontfix
firefox49 --- fixed
firefox-esr45 50+ fixed
firefox50 --- fixed

People

(Reporter: Gavin, Assigned: mattwoodrow)

References

Details

(Keywords: sec-high, Whiteboard: [post-critsmash-triage][adv-main49+]) 

Mats has a patch in progress in bug 881832, so I'm going to assign this to him.  Also, it sounds like this is therefore a layout bug and not DOM?
Assignee: nobody → matspal
Component: DOM → Layout
Hey :mats, any updates here on next steps given we are a couple of beta's away from shipping firefox 27 ?
Flags: needinfo?(matspal)
I still need to figure out the last test failure in bug 881832, which has proven rather
elusive so far.  Besides, the patch in bug 881832 has a high risk for regressions so
I wouldn't recommend it for beta.
Flags: needinfo?(matspal)
(In reply to Mats Palmgren (:mats) from comment #3)

We're a couple of betas into FF28 now - if comment 3 is still the case, we can no longer track for 28 anymore.  Please update with current status.
Flags: needinfo?(matspal)
No change since comment 3.
Assignee: matspal → nobody
Flags: needinfo?(matspal)
Clearly tracking this isn't useful.
tracking-firefox28: + → -
tracking-firefox29: + → -
Group: layout-core-security
Jet, is there somebody who can get bug 881832 over the finish line?  This sec-high bug is almost a year old now.
Flags: needinfo?(bugs)
Working on it...
Johnny, can you please find somebody to work on this? The actual work is happening in bug 881832, which has had a reviewed patch since June 2013, but it causes test_hover.html to fail. Every few months somebody unbitrots the patch and confirms that the test still fails but nobody has actually fixed it yet, and that has been going on for two years now. Thanks.
Flags: needinfo?(bugs) → needinfo?(jst)
Group: core-security
In bug 881832 there is some pretty recent work and we seem close to a fix.  

Since this is sec-high, I'd like to track it for 47 in hopes we can make progress.
status-firefox47: --- → affected
tracking-firefox47: --- → +
mats, any luck here? I would love to get this fixed in 47.
Flags: needinfo?(mats)
Sec-high issue that is tracked for 47, changing the flag to blocking so it gets some attention.
tracking-firefox47: + → blocking
Flags: needinfo?(mats)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11)
> mats, any luck here? I would love to get this fixed in 47.

Not really, I've tried a few times to sort out the issues in bug 881832,
but it doesn't seem to work, so I have given up on that one, sorry.
Matt has some patches up for review in the public bug, so I'll assign this to him. Hooray!
Assignee: nobody → matt.woodrow
Flags: needinfo?(jst)
Removing the blocking flag as we have had this issue for a few releases now.
status-firefox47: affected → wontfix
tracking-firefox47: blocking → +
I don't actually have access to the bug in comment 0, but I believe my patches in bug 881832 are sufficient to fix this.
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49: affected → fixed
Resolution: --- → FIXED
Group: layout-core-security → core-security-release
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
[Tracking Requested - why for this release]:
We should have landed this one on ESR-45 to go with the 49.0 release. Too late?
status-firefox48: affected → wontfix
tracking-firefox-esr45: --- → ?
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main49+]
Alias: CVE-2016-5283
Summary: <iframe src> fragment timing attack can steal private data → <iframe src> fragment timing attack can reveal private data
We had several chances to get this in 49. The patches in bug 881832 are kind of large and look to be related to bugs in Google Docs, sheets, etc. I haven't sorted out whether those bugs were regressions caused by it and now fixed, or whether they were made dependencies later to make it clear what fixed them. But I'm reluctant to uplift this to ESR until we see what kind of regressions pop up once it hits the release channel. This looks to me like the sort of change where we may not get the same broad user coverage on beta as we will on release.
Please feel free to argue otherwise - I'll leave this as tracking-esr45:? for the moment.
Depends on: 1279202
Depends on: CVE-2016-9905
Depends on: 1273827
When this lands on ESR we should also uplift the fix for bug 1293985 and likely other from the depends-on bugs mentioned here. Matt, does that make sense to you?
Flags: needinfo?(matt.woodrow)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #20)
> When this lands on ESR we should also uplift the fix for bug 1293985 and
> likely other from the depends-on bugs mentioned here. Matt, does that make
> sense to you?

Yes, definitely.
Flags: needinfo?(matt.woodrow)
Andrei, making sure you have access to this bug for testing ESR.
Looks like this landed 6 days ago on esr45, in bug 881832.
status-firefox-esr45: affected → fixed
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.