I think delaying every single cached load the browser does to mitigate
this attack is a poor first line of defense. To be practical, the
approach requires a fair amount of browser-specific DOM-foolery®: see
the comments in the source at
http://lcamtuf.coredump.cx/cachetime/firefox.html. Perhaps we can go
after the hack to sidestep timer resolution clamping, or some of the
other browser-specific stuff. Most attacks are also likely to
request, then cancel w/o rendering, a lot of URIs from domains that are
otherwise not represented on the page: if we detect that's going on, we
could take countermeasures (delaying cache loads just for that page,
warning user, etc).
Also, this attack is a variation on an issue that's been known since at
least 2000, with the main difference that this version is
non-destructive (i.e. doesn't change the cache, so it can be repeated
without messing up its own results). If we can change our code so that
changing src= mid-load calls some new form of Cancel that either causes
the URI to be loaded and cached anyway, we can make this attack
cache-destructive once again, and be back to the status quo of the past
10 years. I'm not sure how urgent even that level of mitigation is,
though: it seems to me that most users in the world who have real
reason to fear consequential implications of their browser history being
exposed are being tracked by other means (their ISP/government is spying
on them). Perhaps I'm under-reacting.
Jason
On 02/29/2012 05:35 AM, Patrick McManus wrote:
I'm going to suggest dev-tech-network is the wrong level to be making
this decision. (Ironic, I know - I'm always pushing stuff at d.t.n).
But in this case this should be decision driven, imo, by the product
teams (performance regression!) and the privacy teams. They are in the
position to manage the tradeoff. If they come to a conclusion that this
should be done if the hit is within some cost boundary then d.t.n seems
like the right place to work on making that happen, fill out a product
feature, etc.. I would ask those teams to really consider, at least in
the initial pass, the question of "how much of a performance hit is this
worth to you upfront" rather than punting it back and saying "how much
would this cost?".
On Tue, 2012-02-28 at 21:56 -0800, Zack Weinberg wrote:
On 2012-02-28 4:06 PM, Brian Smith wrote:
Henri Sivonen wrote:
Are there any plans to include the referring origin in the cache
key to address the cache probing history leak that was demoed at
http://lcamtuf.coredump.cx/cachetime/ ?
There is no plan. I suggestion you file a bug (if there isn't one
already).
Please cc: me on the bug. I may be able to help and/or scare up some
student help.
It would be tricky to do, as we would have to avoid major
performance regressions by doing so.
To some extent it *has* to regress performance, because this is a timing
attack: when the attack site tries to iframe something, it has to
*appear* to not be in the cache, even if it is, and that means delaying
the load.
I have no idea whether this is feasible with our cache architecture, but
in principle it would be possible to record the original load time for
each cached item. Then, when we see one of these cross-domain loads
that has to appear to be a miss, we could delay the load for that much
time (with some randomization) but not actually hit the network. That
might mitigate secondary performance hits from having to waste a network
channel on stuff we already have but can't admit to having. On the
other hand, an even sneakier attacker might be able to find a way to
detect *this* behavior... but that's the arms race for ya.
zw
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
