New JavaScript-Based Timing Attack Steals All Browser Source Data

Trailrunner7 writes "Security researchers have been warning about the weaknesses and issues with JavaScript and iframes for years now, but the problem goes far deeper than even many of them thought. A researcher in the U.K. has developed a new technique that uses a combination of JavaScript-based timing attacks and other tactics to read any information he wants from a targeted user's browser and sites the victim is logged into. The attack works on all of the major browsers and researchers say there's no simple fix to prevent it."

Re:Yes, there is a simple fix

[Teun]

Today I booted up the WinXP partition on a netbook that normally runs Kubuntu, last time was over a year ago and I thought why not update now it's still possible.

Java popped up explaining there was an update and I let it install.
Once the install was done I was surprised by being asked my permission to run a check on the Java website, I was even given the option to tick a box to 'always trust Java from this publisher'.

Does the latest Java version now have such a site by site or publisher dependent protection build in?

Mitigation strategies

[Natales]

TFA is correct that there isn't anything to patch per se. However, it's possible to mitigate the effects of this by using multiple completely isolated browser sessions for different purposes. Your banking VM should always be used for banking, nothing else. Clear cookies and browser history at the end of the session. All that while other VMs should be used for their own specific purposes with their own security configuration.

This is very well implemented in Qubes OS [qubes-os.org] but can also be implemented via regular VMs. The guys at Bromium [bromium.com] have also an interesting approach to this issue via microvirtualization using hardware.

Net/net, the important thing is to make sure that whatever the attacker can get, it's irrelevant in the big picture of things.

Link history plus screenshots of iframe content

[Tetravus]

So the guy figured out that browsers render all links on a page and then reflow any that should by styled to indicate they have already been visited. Apparently you can figure out which links have been reflowed by checking the number of frames that have to be rendered to display a link. Not a big deal, and if your site uses the same style for links that are already visited, not an actual attack vector.

The second attack, using SVG (or, I assume) canvas to create a screenshot of what's visible to the end user could be leveraged for an actual attack, you know, if everyone didn't put iframe busting code on their pages served over SSL. Vendors can update the SVG rendering system to adhere to the same cross domain restrictions as other components and not include pixels from iframes in the buffer that is available to inspect via JS and this hole will be closed.

Not too much to worry about here, but I'm surprised that SVG doesn't already do this (canvas won't allow JS to work with cross-domain images unless they have been served with a header that marks them as "safe" according to their originating service).

This is great news!

[StripedCow]

The attack works on all of the major browsers and researchers say there's no simple fix to prevent it.

This may mean that the web will finally be properly redesigned from scratch, using modern insights!
It's about time!

I, for one, am looking forward to running webpages in near-native-speed virtual-machine sandboxes!