Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New JavaScript-Based Timing Attack Steals All Browser Source Data

samzenpus posted about a year ago | from the protect-ya-neck dept.

Security 167

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

Sorry! There are no comments related to the filter you selected.

Yes, there is a simple fix (2, Informative)

Anonymous Coward | about a year ago | (#44470129)

Disable Javascript.

Re:Yes, there is a simple fix (3, Informative)

Anonymous Coward | about a year ago | (#44470159)

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 (2)

Joce640k (829181) | about a year ago | (#44470171)

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

No JavaScript == No Web. (2, Insightful)

Anonymous Coward | about a year ago | (#44470201)

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

Anonymous Coward | about a year ago | (#44470243)

This is just not true. Most of the sites I visit work fine with JS off (NoScript). Any site using Unobtrusive JavaScript will work fine. I use SSBs for the ones that require credentials and require JS. In other cases, I just don't use the site.

Second, add RequestPolicy. Then you can enable JS per-site but be free from all of the cross-domain attacks*. It also requires that you build up a whitelist, but makes you MUCH safer online.

*won't help with stored XSS, but not much will without major changes.

Re:No JavaScript == No Web. (2)

MightyYar (622222) | about a year ago | (#44470303)

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.

Re:No JavaScript == No Web. (0)

Anonymous Coward | about a year ago | (#44470601)

You read religious sites?

Research has proved that porn sites have a better than average score on trustworthiness. Porn sites don't want to be known to be an attack vector for viruses, etc. That is because porn sites' primary business is their website and they don't want to mess with that.

On the other side of the scale are religious sites who just don't do any kind of due diligence on what kind of advertisements they show and if they contain viruses, and also don't really care. Because religion's primary business is done through multiple channels of which the web is just a small one.

Re:No JavaScript == No Web. (1)

interval1066 (668936) | about a year ago | (#44471151)

I started allowing JavaScript to use even, uh, less than trustworthy sites.

Well, that's on you. I use it too to good effect. I have a few web sites I trust more than most, but I still disallow popups, scripts from 2nd level sites, and it appears to prevent cross site scripting effectively enough. Not using it... what's your point?

Re:No JavaScript == No Web. (0)

Joce640k (829181) | about a year ago | (#44470497)

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.

There's a reason you're posting AC...?

a) Your story sounds unlikely
b) If you think your security is worth less than a mouse click then you'll get the browsing experience you deserve.

A JavaScript Fix (0)

Anonymous Coward | about a year ago | (#44470709)

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.

Re:No JavaScript == No Web. (0)

Anonymous Coward | about a year ago | (#44470791)

Slashdot works without Javascript.

Javascript DL from the sites you visit regularly is one thing. Javascript from sites you don't visit regularly is another.

Blocking all javascript by default is a Good Thing.

Re:No JavaScript == No Web. (1)

Anonymous Coward | about a year ago | (#44471245)

I think people mistake NoScript as being a "disable Javascript" button. It's not. It's a control on what parts of the modern web you want to allow. It's not for everyone.

Saying "no javascript == no web" is also a myth. If you're like me and consider social media stuff to be a nuisance as you browse the casual web, then NoScript is a panacea. After two weeks, I had 99% of my web properly working with a very conservative set of filters. Moreover, I only have to "temporarily allow" the top-level domain of 99% of the remaining sites, and those only crop up a few times in a day for me, at most.

In fact, it's only lazy sites that don't show their content WITHOUT Javascript that are a problem, and I've reached the point where I'll just shut the site down if it's that crappy. And you know what? That policy has made my web browsing experience better, not worse. I don't have as many hangs, pauses, hiccups, stutters or random BS happening as I browse.

In short, NoScript is fine if you aren't so badly dependent on the "modern web" that it runs your daily life, rather than it being part of your daily life.

Re:Yes, there is a simple fix (1)

noh8rz10 (2716597) | about a year ago | (#44470203)

web 1.0 ftw!

Re:Yes, there is a simple fix (2)

datavirtue (1104259) | about a year ago | (#44471265)

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 (5, Informative)

dicobalt (1536225) | about a year ago | (#44470173)

NoScript is your friend.

Re:Yes, there is a simple fix (3, Informative)

Anonymous Coward | about a year ago | (#44470383)

Other fix: disable iframes,

Re:Yes, there is a simple fix (1)

kesuki (321456) | about a year ago | (#44471137)

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. it's not like tabs because with tabs each site is on it's own tab as big as the window, with multi framing browsers you can literally load dozens of websites, adjust their frame size and scroll content in interesting ways. it is superior to tabs in every way. you could for instance load a porn site in a 10x480 pixel frame and drag and resize when the coast was clear while you were waiting on it to load perhaps in a place where you wouldn't dare open porn. sure we don't wait for porn to download anymore but at the time we did and it was essential to not show the url of the loading porn pane/frame.

Re:Yes, there is a simple fix (1)

wonkey_monkey (2592601) | about a year ago | (#44471297)

That doesn't sound very useful to me. You said AOL bought it and "killed the tech" but if it was really such an amazing interface someone else could have replicated it.

scroll content in interesting ways

What ways are there except for uppy-downy and lefty-righty? ;)

it is superior to tabs in every way. you could for instance load a porn site in a 10x480 pixel frame and drag and resize when the coast was clear

How is that any difference from switching between tabs? Or switching a separate browser window?

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44471195)

You'd be surprised at how many legitimate sites are using iframes for things that would be very non-trivial to do without. Websites from large companies with multiple groups working on different aspects of a product will create a seemingly seamless experience by iframing one group's content into the other's.

Also, almost every single rich text editor on the web uses at least one iframe.

Also, the same tricks can be applied with traditional frames too, so you'd have to disable those as well.

Re:Yes, there is a simple fix (4, Informative)

plover (150551) | about a year ago | (#44470415)

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 (0)

Anonymous Coward | about a year ago | (#44470441)

The only "great content" javascript offers is ads and intern-generated page bloat.

Re:Yes, there is a simple fix (1)

plover (150551) | about a year ago | (#44470921)

The only "great content" javascript offers is ads and intern-generated page bloat.

JavaScript is not great content. JavaScript enables greatly increased usability of content.

Website owners can and should use the tools at their disposal to present and manipulate content in a way that makes it interesting, fun, informative, and usable. But that shouldn't extend beyond their data. They should also accept responsibility for the safe presentation of other content, like ads. And dynamic execution and safety are at opposite ends of the spectrum.

Re:Yes, there is a simple fix (1)

Oligonicella (659917) | about a year ago | (#44470931)

Simply untrue, regardless of how you meant it.

Re:Yes, there is a simple fix (1)

marauder (30027) | about a year ago | (#44470963)

A lot of people load their JQuery libraries or whatnot from a CDN. In fact I think that's the preferred behaviour. There are multiple CDNs so the list is a bit longer and more annoying than you'd think.

Some links for background:
http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/ [encosia.com]
http://royal.pingdom.com/2012/07/24/best-cdn-for-jquery-in-2012/ [pingdom.com]

Re:Yes, there is a simple fix (1)

pmontra (738736) | about a year ago | (#44471237)

As a noscript user I have to allow cloudflare or many sites don't work. Many sites don't degrade gracefully nowadays and they put their main js on accelerators like cloudflare.

Re:Yes, there is a simple fix (1)

jfengel (409917) | about a year ago | (#44471303)

They also like to link to sites like jquery and google and other sites who are hosting basic Javascript features that they depend on. I'd just as soon they download it and serve it from their domain, but that way they get automatic, dynamic upgrades and bug fixes.

Re:Yes, there is a simple fix (3, Informative)

jfengel (409917) | about a year ago | (#44471283)

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 (2)

J_Darnley (918721) | about a year ago | (#44470185)

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 (1)

edrobinson (976396) | about a year ago | (#44470211)

Wrong. Take a look at the page source...

Re:Yes, there is a simple fix (1)

J_Darnley (918721) | about a year ago | (#44470251)

I see lots of tags but I believe they are rendered completely ineffectual thanks to NoScript.

Re:Yes, there is a simple fix (1)

Opportunist (166417) | about a year ago | (#44470323)

You believe? What is this, faith based science? :)

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44470421)

You believe? What is this, faith based science? :)

I believe so, yes.

Re:Yes, there is a simple fix (2)

maxwell demon (590494) | about a year ago | (#44470507)

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 (0)

Anonymous Coward | about a year ago | (#44471089)

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.

Sure there are. You just can't see them is you have NoScript enabled...

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44470917)

Sorry, can't see your reply with javascript disabled. Users who aren't logged in wouldn't be able to change their comment score threshold setting. I don't know if they can change it while logged in, as I don't have an account myself.

Re:Yes, there is a simple fix (2, Interesting)

Teun (17872) | about a year ago | (#44470263)

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 (0)

Anonymous Coward | about a year ago | (#44470355)

Once again: Oracle Java Runtime Environment (JRE) is not Javascript. Please people - stop conflating Java with Javascript. They are very very different things.

as far as your off-topic Java question: JRE has had publisher checks for many versions. JRE 1.7.x did also add checks for unsigned code and defaults to prompting instead of just blindly running it.

Re:Yes, there is a simple fix (1)

Anonymous Coward | about a year ago | (#44470901)

Java has always had publisher validation for signed applets. The difference with signed applets is that, if the signature is "trusted", they get full run of your system outside the web applet sandbox.

For example, they can read, create, and/or modify any file in your client filesystem to which you have appropriate permissions, and they can do this without any further user interaction or prompts. I believe they can also open network connections which bypass the browser origin logic, so they can send and receive file data or launch attacks to anywhere reachable by your network connection.

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44470757)

So, this isn't an option for you, until after you've been had? At what point will the risk of attack (ie. loss of money) outweigh the usefulness of the sites? $100? $1000? $10000? For me, it's $0. Prevention is better than a cure, isn't it?

Re:Yes, there is a simple fix (1)

10101001 10101001 (732688) | about a year ago | (#44470781)

You might as well stay off of the Web then.

Really? No other options, like, oh, pestering a lot of web site owners to stop using so much damn javascript that sites "need" it?

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.

Well, there's your problem. What part of sanity is there in using the same session/cache/whatever for banking, your brokerage account, your financial sites, etc and "all other content"? Even if javascript wasn't shown to be exploitable, browsers are such leaky messes (no offense intended to the developers, but it's a pretty honest truth) that as much as using a VM just for your financial stuff sounds extreme, it's not really unreasonable. So, like, keep your financial stuff separate (use Firefox/Chrome for business and the other for everything else), preferably on an encrypted volume and you can keep your javascript on since there won't be anything "worth" stealing (or use three or use private browsing or disable javascript except for those few financial sites and clear the cache before/after and restart the browser before/after using those sites).

Unfortunately, JavaScript has become a necessity for the Web.

No. Fortunately, lots of websites have offered a very convenient filter where I can ask myself, "is it worth it to me to enable javascript to view their content" *before* I potentially get exploited. Because that's basically the situation now.

I can't think of any website that actually worked without it.

You can count Slashdot heavily in that. Technically it works, but it doesn't work well without javascript enabled.

As an aside: Tthis is why full disclosure is so damn important. The sooner the public is told, the sooner they can take action. It's only a few clicks to disable javascript, and now I can leave it off until either (a) the article is shown to be overly reactionary, (b) fixes are introduced, or (c) I decide to otherwise mitigate the risk (selective use manually or through an add-on, disabling parts that make me more vulnerable, etc). For all your talk about how much the web needs javascript, the truth is plenty of people (maybe not you) can actually live well enough without it most or all the time. Of course, I think some people (the GP might be one) just have it in for javascript because (a) it's a bad idea to have a turing complete language running from every website, (b) javascript causes all sorts of messes with web readers, different/limited browsers, and (c) situations like this make there appear to be so much lock-in to javascript that it's more of a pain to deal with. But, I think as reactionary as the GP's comment is (when the author was clearly speaking of fixing Javascript in the context of the vulnerabilities, not of per se fixing the javascript concept), I think your response is on the same scale. The second you see as javascript as a need instead of a useful too, javascript is clearly being used too badly to be accepted as is. That's why I mentioned complaining to website owners because that's where you have to start.

Re:Yes, there is a simple fix (1)

gl4ss (559668) | about a year ago | (#44470175)

or add random delays to drawing and fix the bugs which allow viewing of other sites sources and screenshotting.

those are really the bigger thing than finding out if a link has a visited class applied on it or not.

Re:Yes, there is a simple fix (1)

AchilleTalon (540925) | about a year ago | (#44470207)

Yes, adding random delays from the browser should fix the problem for the timing attack.

Re:Yes, there is a simple fix (1)

plover (150551) | about a year ago | (#44470587)

Random delays only delay an attacker, they may not prevent it.

Let's say you had a reply that took 25 milliseconds if it was cached, and 75 milliseconds if it wasn't. To fix it, you add a delay from 0-100 milliseconds to a reply. The attacker would just have to repeat his attack about six times to see the average response time. He'd figure it out soon enough.

Re:Yes, there is a simple fix (1)

gl4ss (559668) | about a year ago | (#44470891)

well, always act like the link was visited before or like it never was.

getting the contents of iframes is the bigger issue here anyways, I'm not sure why he is making such a big deal about the timing attack since the timing attack in principle has nothing to do with the iframe contents peeking or the gfx effect filter bug ??

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44470213)

The other fix is to only visit sites that don't store sensitive information in the page source and don't run arbitrary javascript form untrusted sources. Once an attacker is running whatever JS he wants in your browser, its kinda game over anyway. This doesn't seem like anything to be worried about, unless I'm missing something.

Re:Yes, there is a simple fix (1)

mark-t (151149) | about a year ago | (#44470261)

JS still runs in sandbox and can't access any information stored on your local machine that is not provided to it by the browser, nor, if the browser is running javascript correctly, will the browser's JS interpreter allow access to any information outside the page or any of its frames, that it is presenting to the user from where the javascript code started.

I don't see how any of these proposed attacks would affect somebody who, whenever they are going to go to a site that they may regularly use or have bookmarked, and which may have some confidential information, always manually opens a new tab or window first for the page to load in.

How is even a malicious javascript code on one web page going to see the the content of a page that I have manuallly opened up in an entirely separate window?

Re: Yes, there is a simple fix (1)

h2oliu (38090) | about a year ago | (#44470295)

Not all sites use their own code. Malicious JavaScript through advertisements would provide an attack vector. (As described in the article.)

Re: Yes, there is a simple fix (1)

maxwell demon (590494) | about a year ago | (#44470531)

Only if it gets executed. Why would you enable the JavaScript from ad networks to execute on your browser?

Re: Yes, there is a simple fix (1)

mark-t (151149) | about a year ago | (#44470565)

Why wouid any remotely reputable place that has any genuinely confidential information about a person be using third party javascript hosted elsewhere linked from a page where such confidential information might be getting used?

because they aren't reading security news, or oops (1)

raymorris (2726007) | about a year ago | (#44470973)

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.

Re:Yes, there is a simple fix (1)

Concerned Onlooker (473481) | about a year ago | (#44470345)

The article is not informative enough. For instance, malicious code determines what web sites you've visited based upon the rendering time for a link. However, that begs the question that it must require rendering a page that has the links someone is interested in finding out you're visited. The article doesn't elaborate much so it doesn't seem as though there is arbitrary access to the browsing history.

I would love to hear more from someone more knowledgable about this technique.

Re:Yes, there is a simple fix (1)

mrnobo1024 (464702) | about a year ago | (#44470581)

How is even a malicious javascript code on one web page going to see the the content of a page that I have manuallly opened up in an entirely separate window?

It can't, but it can load that same page's URL in an iframe, and it will contain the same confidential information. Browsers try to prevent pages from reading the contents of cross-domain iframes, which is extremely difficult to do in a completely airtight manner. A much better solution would be not sending cookies on cross-domain requests and thus making it impossible for one site to load the secrets a different site is storing for you, but so far everybody is focused on treating the symptoms and not the disease.

Re:Yes, there is a simple fix (2)

akh (240886) | about a year ago | (#44470909)

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 (1)

Anonymous Coward | about a year ago | (#44470233)

Disable Javascript.

The fucking assholes in the Firefox project decided against all common sense to take away the option to disable javascript on a global/per site.
But hey, the modern rage is all about taking away options so...

Re:Yes, there is a simple fix (1)

colinrichardday (768814) | about a year ago | (#44470929)

I can globally disable javascript on firefox: edit -> preferences -> content -> uncheck the enable javascript box. I don't know about per site.

Re:Yes, there is a simple fix (0)

Anonymous Coward | about a year ago | (#44470337)

Not a realistic solution. Might as well say don't use the internet.

Re:Yes, there is a simple fix (1)

squiggleslash (241428) | about a year ago | (#44470535)

Also disable CSS and HTML. You can never be too careful...

No easy fix (1)

Anonymous Coward | about a year ago | (#44470133)

like disabling javascript?

Re:No easy fix (1)

Mitchell314 (1576581) | about a year ago | (#44470287)

Or just port the browser over to Java. Then the attack can't tell between a slow link, or the obnoxious garbage collector kicking in. :P

No simple Fix? Turn off JavaScript. (1)

Anonymous Coward | about a year ago | (#44470135)

Seems like turning off javascript should be a simple fix to a javascript based attack.

Re:No simple Fix? Turn off JavaScript. (1)

Horshu (2754893) | about a year ago | (#44470299)

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

Re:No simple Fix? Turn off JavaScript. (0)

Anonymous Coward | about a year ago | (#44470347)

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

harsh reality of bad technology (0)

Anonymous Coward | about a year ago | (#44470513)

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.

Re:No simple Fix? Turn off JavaScript. (2)

maxwell demon (590494) | about a year ago | (#44470561)

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.

Is Flash for anything but ads and games? (1)

raymorris (2726007) | about a year ago | (#44471017)

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.

Self-referential story? (1)

Tim Ward (514198) | about a year ago | (#44470141)

My browser won't let me open the target web site because it thinks it's nasty!

Re:Self-referential story? (1)

Smivs (1197859) | about a year ago | (#44470255)

Ha, yes I got that as well :) You using Opera?

that sucks (0)

Anonymous Coward | about a year ago | (#44470147)

that sucks

You mean the internet is full of danger? (1)

Bob_Who (926234) | about a year ago | (#44470205)

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.

FrisT psot (-1)

Anonymous Coward | about a year ago | (#44470223)

fucking surprise, Clothes or be a they are Come lubrication. You surveys show that Be a cock-sucking Wash off hands of the old going sales and so on, Else up their asses one or the other that the project [tuxedo.org], new faces and many truth, for all happiness Another are inherently of challenges that and Michael Smith about outside gains market share your own beer to happen. My knows for sure what come Here but now slings are limited, it simple, at my freelance had at lunchtime Pooper. Nothing BSD machines, very distracting to be on a wrong time wholesome and reformatted sse... The number of OpenBSD versus something done on baby...don't forwards we must Of the warring

Mitigation strategies (3, Interesting)

Natales (182136) | about a year ago | (#44470297)

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.

Re:Mitigation strategies (2)

omz13 (882548) | about a year ago | (#44470841)

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.

Re:Mitigation strategies (0)

Anonymous Coward | about a year ago | (#44470845)

Or use Sandboxie!

Firefox (0)

Anonymous Coward | about a year ago | (#44470301)

Then again, Mozilla wants to get rid of the option to turn off javascript.

Re:Firefox (0)

Anonymous Coward | about a year ago | (#44470471)

A Firefox extension will only be made to disable it, if it cannot be natively disabled. There are already ones that disable it on a per-site basis like NoScript.

Simple fix: strip iframes (1)

Anonymous Coward | about a year ago | (#44470313)

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?

Re:Simple fix: strip iframes (1)

minstrelmike (1602771) | about a year ago | (#44470397)

That's what I was wondering--no iframes.
And for the folks who hate javascript for whatever reason, apparently they think they can substitute an UNBREAKABLE software for it.
Clue for the clueless--software is only unbreakable when it remains unpopular.

Re:Simple fix: strip iframes (1)

The MAZZTer (911996) | about a year ago | (#44470685)

I think you underestimate just how many sites rely on frames. Gmail uses them for some functionality for one, though I dunno how critical it is.

Re:Simple fix: strip iframes (1)

pmontra (738736) | about a year ago | (#44471281)

iframes are the only safe way to inject css and js into a third party page with no fears of conflicts with local code. Think of widgets, Facebook social widgets were using iframes last time I checked.

The sky is falling!! (0)

Anonymous Coward | about a year ago | (#44470319)

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

The fix for about any timing attack (1)

Opportunist (166417) | about a year ago | (#44470365)

Fuck with the timing.

Huh? What do you mean, "that would require today's programmers to at least know OF Assembler"...

Just render the link twice always... (0)

Anonymous Coward | about a year ago | (#44470367)

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

Link history plus screenshots of iframe content (3, Interesting)

Tetravus (79831) | about a year ago | (#44470369)

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

Re:Link history plus screenshots of iframe content (0)

Anonymous Coward | about a year ago | (#44470467)

Is that literally all it was?
Haha oh wow, that crap is trivial to fix.

The history thing has been known forever under another method. I assume history will now be taken out of the DOM state changes entirely and only same-domain history will be capable of being styled. It should have been like that in the first place anyway!

And Screenshot abuse has been looked in to before.
Hell, it wouldn't matter since you can re-render an entire DOM simply by dumping the entire thing in to binary, encoding it to an image and transmitting it wherever in as little space as possible. On a JS-heavy page, a user would probably never notice.
The whole DOMs state is there for the taking, a screenshot feature will just make it simpler, but not impossible, to code.

Re:Link history plus screenshots of iframe content (1)

Gavagai80 (1275204) | about a year ago | (#44470541)

Only styling visiting links on the same domain would be breaking the feature. The point is to be able to read a page of links and see quickly which of the linked websites you've already been to (if you're working your way through a list or the like). That said, I don't this "exploit" should be fixed since all it can do it find out which of a small set of the most popular websites someone has been to... what can someone do with that, serve better targeted ads?

Re:Link history plus screenshots of iframe content (1)

Impy the Impiuos Imp (442658) | about a year ago | (#44470727)

Is he saying he can do all this by serving up, from, say, his server and web page, Javascript code that will figure out all this other stuff you do visiting other sites on the same session?

If so, I suppose they could encapsulate each web domain so it can't interrogate the Java engine as a whole, i.e. yet another layer of virtual machine.

Re:Link history plus screenshots of iframe content (1)

93 Escort Wagon (326346) | about a year ago | (#44470783)

Yes, at least as the linked story explains these vulnerabilities - he'd have to lure you to a page or else have code running on your computer to effect these attacks.

Also, "reading any information he wants" seems to actually be "see which linked websites youve previously visited on this page I control" and "see the contents of iframes if I have a way to run some other code on your computer or have physical access to it".

These could turn into serious vulnerabilities - but the summary contains significant hyperbole.

Re:Link history plus screenshots of iframe content (1)

dk400 (1099671) | about a year ago | (#44470779)

AFAIK, reading visited links by a user is pretty much worthless. it is not an attack per-se. It is like my neighbor sees me throwing out an used empty milkcan every week, and realizes I am gulping a milkcan every week. what do you with that ephemeral information? there are sites that I visit everyday for just few minutes and then there are sites that I spend more than 1 hour on a particular day and never return to them in more than a week or two !

css change? (2)

minstrelmike (1602771) | about a year ago | (#44470401)

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

Re:css change? (2)

Noishe (829350) | about a year ago | (#44470711)

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? (2)

JDG1980 (2438906) | about a year ago | (#44471347)

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? (0)

Anonymous Coward | about a year ago | (#44471255)

If you do that you are following current web design trends!

CSP (0)

Anonymous Coward | about a year ago | (#44470451)

Sites have Content Security Policy HTTP headers they can set to prevent being put into an iFrame.

Not too bad if developers do things right (1)

TomGreenhaw (929233) | about a year ago | (#44470597)

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.

It's simple, we kill the Batman (1)

jfdavis668 (1414919) | about a year ago | (#44470607)

I'll solve this for half.

This is great news! (3, Interesting)

StripedCow (776465) | about a year ago | (#44470673)

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!

Re:This is great news! (0)

Anonymous Coward | about a year ago | (#44470737)

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

Yeah, and all corporate encryption and NSA backdooring you can handle, right?

Most likely, whatever follows will rely on security thru obscurity more than being open to all. It won't *actually* be more secure, but it will have more theater surrounding it, so it will *sound* better.

Slashdot Uses JavaScript (1)

DERoss (1919496) | about a year ago | (#44470787)

The Slashdot Web site makes extensive use of JavaScript. If the article is accurate, does that mean Slashdot will abandon such use?

safety is an illusion anyway (2)

Connie_Lingus (317691) | about a year ago | (#44470795)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?