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.
like disabling javascript?
Seems like turning off javascript should be a simple fix to a javascript based attack.
My browser won't let me open the target web site because it thinks it's nasty!
that sucks
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.
I thought it would be secure like my telecom....
Sanitary like the stadium men's room.
And trustworthy like my bank and credit score.
Now I am very upset that I'll just have to wear clothing in public, once again. There goes the neighborhood.
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.
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. Better fix would be for the browsers to allow disabling JS on a per-site basis, or better yet, allowing disabling of individual JS APIs (yeah, it could turn site behavior into a clusterf$%k, but I would give up red meat to be able to disable window.open())
Then again, Mozilla wants to get rid of the option to turn off javascript.
Javascript seems like it would be the easier fix (I use three browser for different tasks one of which is everyday browsing and it has javascript turned off.) but javascript is necessary for pretty much everybody. Think GMail and Google Maps. Sure Google could support Thunderbird and have native map clients for everybody but that would require a lot of work( arguably less since javascript is so nasty, but they have kludged around that for the most part already...) So the simpler answer is a no frames/iframes checkbox in Firefox. Or think of it another way how many fewer adds would we have?
>Firefox has fixed the pixel-reading issue
So one of the more worrisome ones was fixed already? Ok. I don't think the view-source one will be any trouble either.
>Essentially, the browser draws the link as un-visited and then makes a database query to see whether the user has visited the link. If so, it then redraws the link as visited.
And this is the less worrisome one? Come on. What's impossible about fixing this? Doesn't Mozilla already not bother repainting the links as visited until the user hovers their mouse over them? What's so hard about fixing this?
Well, since you are probably using an open source browser, you can disable window.open(). You'll have to give up some time (or money) though, but at least you can still have red meat :)
Fuck with the timing.
Huh? What do you mean, "that would require today's programmers to at least know OF Assembler"...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"There's no simple fix"? For the timing attack, the browser just has to ensure that the timing is the same in either case. Just redraw always. That might have efficiency issues, but it's certainly simple.
That said, using NoScript and keeping javascript turned off as much as possible (like I do on this site and every site I haven't explicitly whitelisted) helps a great deal. This kind of stuff is most commonly done by advertising and "web analytics" sites, not top-level sites.
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).
What if I just change the css so visited and unvisited links are identical?
Would js then redraw anything at all?
Sites have Content Security Policy HTTP headers they can set to prevent being put into an iFrame.
Yep, just like "word".
Just everybody uses "word" and only "word".
HorsePucky!
Like I told the vendors putting crap Flash and crap JavaScript on their www sites; you put crap which prevents me and the purchasing agent from buying your stuff with ease then I will go to another product and include a note in the specifications NOT to buy anything from you because your knowedge and use of technology SUCKS!
Find an alternative - do not 'buy' from asshats!
And while you are at it - stop voting for anbody who continues to allow the monies stolen from you using the crapitalist "tax code" to buy proprietary software.
Not very many sites depend on Flash. Mainly video and online game sites. And there's always the option to whitelist.
The Tao of math: The numbers you can count are not the real numbers.
If you do things in a secure manner (e.g. OWASP top 10) this should not be a big deal. Turning off JavaScript IMHO is awfully extreme and few would do it anyway. Obviously iFrames should be used judiciously because it opens you to a potential for cross site scripting and other undesirable things on your site. Awareness that linking to public libraries is intentional cross site scripting is critical too. Pre-populating content and controls from user supplied text must be filtered, and fields like passwords, credit card numbers and sensitive personal information should never be pre-populated. Thinking that your site visit history is private even without this attack is grossly delusional as there are already many ways this is already tracked, e.g. ad retargeting and Chrome not in incognito mode.
Greed is the root of all evil.
I'll solve this for half.
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.
First, in the JavaScript for a page, set the window.name property. Then you can use the anchor tag a little bit differently from normal. In my experiments I have never seen this kind of link get colored anything other than the specified blue; therefore it must be failing the browser's find-it-in-database-of-visited-pages test.
Here is the code without the first and last angle-brackets:
a id="SLASHD" onclick="window.open('.http://slashdot.org','CurrentWindowPageName');" style="color:#0000ff;text-decoration:underline;cursor:pointer;">Slashdot Home Page
And here is what the link looks like with the first and last angle-brackets:
Slashdot Home Page
This particular code is probably not workable on a Slashdot page because "CurrentWindowPageName" is not the correct name.
The Slashdot Web site makes extensive use of JavaScript. If the article is accurate, does that mean Slashdot will abandon such use?
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.
never bring a twinkie to a food fight.
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.
It's a bad idea, and anyone who studies web security knows that. That includes about 1% of web designers and developers. It seems that there are a lot of people building web sites who know all about color wheels, and don't know what CSRF stands for.
I'm the opposite - I don't know what mauve is, while I have exploited browser vulnerabilties. I've also made errors before, probably much more significant errors than what you referred to.
Now that 99% of video is on YouTube and therefore accessible via html5, is Flash actually used by any significant site for anything but games and ads? I guess a few porn sites use it for video?
For about three years I haven't had Flash installed in my main browser and I haven't missed it. Maybe twice a year I open my other browser to see one of the above.
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.
Javascript could very well be the worst thing that has ever happened to computers.
Security researchers have been warning that client-side browser JS is an utter security disaster for many many years now, to little effect. Security-oblivious webbies are so overwhelmingly fascinated by their ability to control what remote users's browsers do that they just don't care about the security fallout and find all kinds of cute reasons to retain the status quo, and of course organized crime just loves every minute of it.
This latest revelation is just another nail in client-side JS's coffin for anyone who is remotely security-conscious. The clueless and the willfully deaf will continue to use it though, it's inevitable, as JS use is increasing not decreasing. Organized crime will continue to reap the rewards. It's awesome if you're evil.
I'll second (or fifth) the NoScript recommendation. Yes, NoScript can be a bit of a pain in the ass at times, but it sure trims down the the amount of crap that runs. JavaScript wasn't designed with security in mind, so it'll never be secure - they can only spackle over the cracks. Best you can do is minimize how much runs in the cesspit of the Internet. I also find that I only have to allow it for a few regular sites, so once you're past that there's not much maintenance. Most sites still work without it, even if you don't get all the features - for instance, /. is working fine with no javascript allowed at all.
If you don't want the hassle at least install Ghostery and turn off the GhostRank. Most sites are pulling in random JS from 6-12 other sites for tracking/ad/social purposes.
And since most browser malware is delivered by drive-by ads (often through legitimate ad networks who don't realize it), add Adblock to keep those out.
It's also a prophylactic prevention against whatever new zero-days come along since they very rarely can do anything without JS or Flash. I guess we'll see what happens with HTML5...
I'm always amazed when I see someone else go to the same sites I go to and there is SO MUCH CRAP that you can barely find the content. To me that also makes the NoScript hassle worth it.
But a few years ago, a bunch of people had that idea, and now you don't really run into the problem of 'site X depends on Flash'. I can't remember the last time I really needed Flash, it must have been last year, and I even use video streaming sites.
I should RTFA, but it seems unnecessary... LOL. Yes?
Mine is turned off on my surfing machine.
It only prevents me from making comments on some sites I dont care.
I have another machine that sole purpose is to bank.
i remember that before there was iframes there was a cool browser that let you make as many frames from multiple sources and did it all on a 486 with 8mb of ram. sadly aol bought it and killed the tech.
Not sure what browser you're referring to, but KDE's Konqueror browser can do that and is still being developed. Also supports different html engines and can be used as a file manager, too.
For example, here's a screenshot of Konqueror showing the same page (google.com) in three different views: khtml (left), webkit (right bottom), and embedded text editor with syntax highlighting (right top).
Use a totally separate browser context for each different place you want to carry out secure, JavaScript-based, web activities. Although there are other ways (need a little coding), the simplest way to do this is just create multiple users (on your own computer), each designated for visiting the places you need security (one for each bank account, one for each retailer, one for access to work related stuff, etc). Browsers do have special features to do this kind of thing, but I have found they are not as separately isolated as I would like. I'm not so paranoid (yet) to use separate virtual machines, but others might. Three letter agencies are known to use physically separate machines.
now we need to go OSS in diesel cars
That's the real issue ... everyone wants a 'simple fix'. There is not sufficient patience to come up with a real fix. That goes for browser/web security as well as a number of other things that could be substituted in here (economies, gov't poliicies, etc.).
The simple answer is that a simple fix is not what we should be looking at. The real answer starts to get a lot more complicated.