600025 - CSS timing attack on global history still possible with MozAfterPaint

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Zack Weinberg (:zwol)]

Post-bug 147777, it is not supposed to be possible to read global history via timing attacks, but the web page at the URL above seems to be able to do it under some circumstances.  It uses CSS rules of the form

  div[class*="123"] a:visited { color: green }

in conjunction with HTML of the form

  <div class="xxxxxxx..."><a href="[target site]">blah</a></div>

and a listener for the MozAfterPaint event.  There are 400,000 "x"s (and no number at all) in the classname.

Pre-bug 147777, the MozAfterPaint event fires in <5ms for unvisited links, and 300-600ms for visited links.  The test page is very reliable.

Post-bug 147777, the MozAfterPaint event fires in about 600ms for unvisited links and somewhere between 600 and 1200 ms for visited links.  The test page's calibration procedure does not always work, and sometimes an *un*visited link or two takes the amount of time associated with visited links, but overall, the attack still works.

I have not been able to figure out why the attack still works; it *seems* like the patches for bug 147777 should make the selector take the same amount of time regardless.  It is, perhaps, telling that a variation that times synchronous reflow (by reading reflow-dependent DOM properties) does *not* work; only the MozAfterPaint approach works.

Comment 1

[Zack Weinberg (:zwol)]

I should have mentioned that this does not always work -- on some builds/OSes/profiles/phases of moon, everything takes the same amount of time.  *confused*

Comment 2

[Boris Zbarsky [:bzbarsky]]

With visited links, perhaps we just have more stuff in the event queue (due to the events that the history thread posts to notify links when lookups complete)?

Comment 3

[Boris Zbarsky [:bzbarsky]]

More precisely, maybe they're managing to measure the time we take to restyle once we discover the link is visited?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In other words, this could be bug 557579?

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #4)
> In other words, this could be bug 557579?
Yeah, likely.  We don't restyle right now if it's not visited.  Always restyling kinda sucks perf wise though :(

Comment 6

[Dave Webber]

(In reply to comment #5)
> Yeah, likely.  We don't restyle right now if it's not visited.  Always
> restyling kinda sucks perf wise though :(
Wouldn't it only be necessary to restyle irrespective of history for links to non-same-origin resources?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Checking the origin is may well be just as expensive as restyling.... Worth measuring, perhaps.

Comment 8

[Zack Weinberg (:zwol)]

(In reply to comment #3)
> More precisely, maybe they're managing to measure the time we take to restyle
> once we discover the link is visited?

That *sounds* consistent with MozAfterPaint seeing a timing difference but reflow-dependent DOM properties not.  And with MozAfterPaint not always working.

Perhaps a lower-cost fix is to fire MozAfterPaint at the point where we would have done it if there weren't outstanding history queries?  (I have no idea whether this is feasible.)

(In reply to comment #6)
> Wouldn't it only be necessary to restyle irrespective of history for links to
> non-same-origin resources?

I recall the discussion in bug 147777 being generally opposed to having same-origin-ness matter.  With my security researcher hat on, I like that, because it means I can test for this kind of bug without needing two domain names or having to make assumptions on the order of "*everybody* visits facebook.com" ;-)

Comment 9

[Zack Weinberg (:zwol)]

Changing when MozAfterPaint fires may not be airtight, though; I don't *know* one, but there might be some other sneaky way to detect the restyle.

Comment 10

[Collin Jackson]

Attachment: PoC that counts the number of repaints

Here's a test case that counts the number of repaints to determine whether a link is visited on not.

Comment 11

[Collin Jackson]

Attachment: Original timing PoC

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, I think this is just bug 557579.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We can disable the firing of MozAfterPaint events for some or all invalidates, if we have to. It's not that important an API. But it sounds like that doesn't really solve anything, and the timing of paints can still be picked up via mozRequestAnimationFrame, which is something we definitely *don't* want to break.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How does mozRequestAnimationFrame expose whether or not we have anything to paint?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah I guess it doesn't. Never mind!

Note that MozAfterPaint has just changed so that now it actually fires (synchronously) just after painting. That probably doesn't affect this bug though.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed by bug 608030.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, thanks.  I was thinking I needed to file an additional followup bug, but I realize bug 557579 is already filed.

Comment 18

[Aleksei Perepelkin [:chaos]]

Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre