Slashdot Mirror
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."
Disable Javascript.
You might as well stay off of the Web then.
I tried that a couple of times and I couldn't do any banking, use my brokerage account, use any financial sites, all other content would not show correctly.
Unfortunately, JavaScript has become a necessity for the Web.
I can't think of any website that actually worked without it.
NoScript is your friend.
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 but can also be implemented via regular VMs. The guys at Bromium 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.
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).
Other fix: disable iframes,
Javascript is cool for offering great content. But why would anyone allow JavaScript from non-primary-domain sources? Advertisers may want their readers to have an "rich, interactive, dynamic experience". Fine, they can offer that: on their site, after the users click over to your site from a static image.
The rest of the linked-in javascript out there is mostly analytics, which do not benefit you as a user.
And as a web site operator, you can be pretty sure that customers don't want to be pwned just because of a javascript brought in by your site. Should you really be linking to others that offer it?
The GP said "he's whitelisting everything." He's doing it wrong - allow the javascript from servers in the *.domain.com for any given page, then selectively enable it from sites that add on features you care about, like disqus and vimeo. It's not a long list, and once you've whitelisted vimeo and vimeocdn for one site, you're not constantly enabling them on others.
John
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!
If Pandora's box is destined to be opened, *I* want to be the one to open it.
This sort of timing attack was discussed three years ago on the Mozilla blog.
Could someone elaborate on exactly what hasn't been fixed for the Mozilla-based browsers? Dunno about the rest.
Frenemy. Or rather, lots of web sites are my frenemies, scooping up Javascript from dozens of web sites with no clear indication that they're aware of the interactions or trustworthiness of those sites. Slate.com is my particular nemesis here; I once counted two dozen separate sites that would have had to be enabled before the site could run as its designers intended, some of them down 4 and 5 layers of indirection.
NoScript, who treats everybody as an enemy until told otherwise, requires an awful lot of hand-holding before permitting that. NoScript I trust (more or less) to be on my side, but lots of web site designers consider them the enemy, and that makes our mutual encounters... tense.
If enough users disable javascript, sites will be forced to provide a content generating back-end alternative. Js is becoming the new Flash. Opening wide up for vulnerabilities, and draining your laptops battery.