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."

Comments

Yes, there is a simple fix

[Anonymous Coward]

Disable Javascript.

Re:Yes, there is a simple fix

[Anonymous Coward]

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.

Re:Yes, there is a simple fix

[Joce640k]

You could try enabling it on your bank's website.

Re:Yes, there is a simple fix

[dicobalt]

NoScript is your friend.

Re:Yes, there is a simple fix

[J_Darnley]

Only because devs expect to be abe to use it. Interactive websites worked before the lastest fad for JS, and they still do! As for one that works without: you are on one!

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?

Re:Yes, there is a simple fix

[Anonymous Coward]

Other fix: disable iframes,

Re:Yes, there is a simple fix

[plover]

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.

Re:Yes, there is a simple fix

[maxwell demon]

I guess he could have studied the NoScript code (and the Firefox code it interacts with) in detail to make sure that NoScript indeed does what it is supposed to do in all cases. However he decided to not do that work, but instead to trust the author of NoScript to provide what he advertises. Probably encouraged by the fact that there seem to be no publicly known failures of NoScript in this regard.

Re:Yes, there is a simple fix

[akh]

A good defense against this kind of attack is to 1) use a per-page nonce, 2) use an HTTP POST for all page loads, and 3) use HTTPS for all traffic. On every page load the nonce present in the POSTed form is compared to the nonce stored on the server. If the nonces match then the page along with a new nonce is generated and returned to the client; the new nonce also replaces the old one on the server side. If the nonces do not match then an error is returned. Simply knowing the page's URL does not allow one to retrieve the page even if one is seen as being logged in (e.g. via a cookie). In addition, this technique provides a good deal of defense against replay attacks and session hijacking. Note, however, that this technique can be partially defeated if the attacker has some other way of retrieving the source of the actual page displayed in the user's browser. A full security analysis is left as an exercise for the reader ;^)

Re:Yes, there is a simple fix

[datavirtue]

I'm using NoScript which is pretty simple and grants you a lot of control. It saves me bandwidth on my satellite connection and makes the pages load quicker. A lot of the good sites have a decent fallback as well. Facebook is much better without Javascript for instance.

Re:Yes, there is a simple fix

[jfengel]

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.

Re:Yes, there is a simple fix

[plover]

Analytics allow site owners to see interesting data about their pages - how many visits, etc. The owners can theoretically improve their pages so I get a better experience. And it's free! Who doesn't love a free service?

But the well-known rule is that if someone's giving you something for free, you are the product, not the consumer. So they're selling you out the back end. Think about what they now have to sell.

The answer is that the analytics providers are tracking behavior from search to sale. They are able to tell their paying customers "people who search for 'XYZZY' are buying magic wands for an average of 30 gold pieces each. The higher they are on the search results, the closer they are to the average price. There are 10,000 queries for XYZZY from the US each day, and 500 of those result in sales. If you pay for an XYZZY adword, you'll see about 2,500 of those people. Half the people who searched for XYZZY went to MagicWandRatings.com before buying magic wands, and of those their readers chose PLUGH brand magic rods over XYZZY magic wands 10 to 1. Cart abandonment of 40 G.P. magic wands is at 80%, while card abandonment of 38 G.P. magic wands is at 70%."

The first thing my SEO guy is going to do is head to MagicWandRatings.com and create a couple dozen sock puppets to tout XYZZY wands. He's going to lie his butt off telling people that XYZZY wands are the fierce green snake's pyjamas. MagicWandRatings.com, once the most trusted site in magic wand ratings, is going to become an unreliable source of information regarding wands thanks to this pollution, yet the search engines are going to continue to lead me there anyway.

Analytics lets the sellers discover the highest going prices to sell their merchandise at. This results in the highest possible prices for me, the consumer. So I get a high-priced crappy wand as a result of analytics.

As a consumer, analytics ultimately do not benefit me. They corrupt the web and cost me money and quality. Thanks, but I'll opt out.

Re:Yes, there is a simple fix

[jarle.aase]

I agree.

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.

Re:Yes, there is a simple fix

[denmarkw00t]

It's not just security to worry about - although that isn't really a big concern as most CDNs hopefully never fall to exploits themselves...

Working in a "content agency," we've used CDN hosted JS before. Not shabby, but I prefer to keep it on our servers. It doesn't really save you on point B - if you're hosting the page, host the damn JS. The caching is nice, but your JS should be small anyway...hopefully. We ran into an issue with jQuery Mobile over CDN - we were pointing to the latest stable, but surely enough something changed one day and it was enough to throw the page into a sputtering mess...not worth it.

No JavaScript == No Web.

[Anonymous Coward]

You could try enabling it on your bank's website.

Which I did.

The trouble is, very few websites work without it.

In other words, I was whitelisting every website that I visited.

Javascript is used so much, I never came across a website that would function without it.

No JavaScript == No Web.

Re:No JavaScript == No Web.

[MightyYar]

Yup - I used to be a religious user of NoScript, but gave up when I started allowing JavaScript to use even, uh, less than trustworthy sites.

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 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.

Re:Mitigation strategies

[omz13]

That's all very well and good, but do you think the average web surfer even knows what you're talking about? Any solution needs to be baked into the bog-standard browsers instead of asking users to do VM magic.

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).

css change?

[minstrelmike]

What if I just change the css so visited and unvisited links are identical?
Would js then redraw anything at all?

Re:css change?

[Noishe]

yeap. the issue is the browser code, which essentially boils down to:
---
draw link with normal style
lookup link in visited database
if link exists in database
    then draw link with visited style
---
The problem is that visited links get drawn twice, while non-visted links get drawn once. It doesn't matter if the links are styled the same or not, as the browser will still go through the motions, and take additional time in the visited case.

The browser doesn't care if the styles are both the same or not. If it did care, then it would have to do an additional comparison on every style that will change how the link is drawn, which would just be too slow.

Re:css change?

[JDG1980]

yeap. the issue is the browser code, which essentially boils down to:

• draw link with normal style
• lookup link in visited database
• if link exists in database
• then draw link with visited style

Wouldn't the obvious solution be to change the order to lookup the link first, and if the link exists in the visited database, then draw it with visited style, else draw it with unvisited style? That shouldn't be any slower (since the DB has to be checked anyway) and it would eliminate the timing attacks discussed here.

Re:css change?

[VortexCortex]

Yes. When they say that there's "no easy way to fix" something, they mean it would require that one of the coders writing web browsers not be fucking idiots. However, history has proved this impossible.

Re:No simple Fix? Turn off JavaScript.

[maxwell demon]

That's akin to turning off Flash to get rid of ads. Sounds like a good - no, great - idea, until you run into the problem of so many sites depending on it.

Not very many sites depend on Flash. Mainly video and online game sites. And there's always the option to whitelist.

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!

safety is an illusion anyway

[Connie_Lingus]

you know...the locks that (supposedly) protect you and your loved ones and valuables can be easily picked by people with just a tad bit of training and practice...

terrorists will strike again and kill lots of people but the odds are beyond tiny it will be you or anyone you know...

the internet is loaded with potential threats and *maybe* someone will actually build a real site that does everything the article says it can...

i guess im just sick of kneejerk "omfg something is possible so lets all freak out and throw away our freedoms and turn off our browsers and blah blah blah". we live in a world where yes, you just might die in your bed when a giant sinkhole opens up underneath you, and you know what?? that's ok...whats better that we build a giant police state that gives the illusion of security?

oh yeah...the u.s. IS doing that...never mind.

discussed three years ago

[Joining Yet Again]

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.

Re:No simple Fix? Turn off JavaScript.

[0123456]

That's akin to turning off Flash to get rid of ads. Sounds like a good - no, great - idea, until you run into the problem of so many sites depending on it.

I uninstalled Flash a while ago. Other than youtube, I run into maybe one site a month that won't work without Flash, and they're clearly run by retards so I'm better off not going there.