Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixel-perfect timing attacks with HTML5

contextis.co.uk

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Pixel-perfect timing attacks with HTML5

#41

Post by sanderjd »

mistercow wrote: post #29
sanderjd wrote: post #15

Earlier quoted context omitted.

Developing the UI without using JS wouldn't be harder , it would make the UI less usable . As a user of online banking software, I don't think it worked at all as well "before the modern trend of trying to make everything act like a desktop app", I think it totally sucked. Maybe that's a worthwhile security trade-off, but let's at least talk about the real trade-off.

Every online banking site I've used had a UI that could be entirely recreated without using JS, with literally no perceivable difference to the user. I have never once said "Man, I sure wish I could get to my balance without a new page loading when I clicked the link."

It sounds like it is our expectations rather than our experiences that differ wildly. I have many times said that I would like to be able to get to my balance without a new page loading. That and much more. Clearly, "new page loading" isn't really the metric I care about. I care about how quickly and un-frustratedly I can accomplish whatever I'm trying to accomplish. Anecdotally, and limiting the discussion to banking websites, I find the "new page loading" metric correlates with the "slow and frustrating" metric. I get the sense that you feel differently, and I don't think it's worthwhile for me to try to talk you into frustration or you to try to talk me out of it. You may be able to convince me that the frustration of going JS-free is worth the enhanced security, but as of now, there appear to be better solutions.

Re: Pixel-perfect timing attacks with HTML5

#42

Post by comrade_ogilvy »

tptacek wrote: post #17
M4v3R wrote: post #2

These attacks are getting more and more creative. I begin to think that there is no such thing as perfect security in a world that constantly demands new features.

Don't think about security that way; that kind of logic is misleading. Security is measured in dollars, in the sense of cost imposed on attackers. You're right that there's a constant tension between features and security.

Right. To be more precise, security is a set of costs on web developers, web viewers, and attackers. There is no obviously correct way to balance all three, once you start seeing feasible removed/missing features that would be genuinely useful tallied as costs.

Re: Pixel-perfect timing attacks with HTML5

#43

Post by ghostdiver »

zubspace wrote: post #9

The paper describes how to prevent the sniffing attack: Website owners can protect themselves from the pixel reading attacks described in this paper by disallowing framing of their sites. This can be done by setting the following HTTP header: X-Frame-Options: Deny This header is primarily intended to prevent clickjacking attacks, but it is effective at mitigating any attack technique that involves a malicious site lo…

For JS apps this can be done on client side in JS.

  if(top!=self) doNotFetchSensitiveInfoFromServer(true);

Re: Pixel-perfect timing attacks with HTML5

#44

Post by joshfraser »

jffry wrote: post #39
jffry wrote: post #25

Earlier quoted context omitted.

Would X-Frame-Options:DENY work to mitigate the view-source: attack?

Just threw together a test case. X-Frame-Options does seem to mitigate the view-source attack: http://jsfiddle.net/GEynT/2/embedded/result/

To be clear, the hack is still possible without view-source. It just makes it easier and more generic of a solution.

Re: Pixel-perfect timing attacks with HTML5

#45

Post by Qantourisc »

talmand wrote: post #8
M4v3R wrote: post #2

These attacks are getting more and more creative. I begin to think that there is no such thing as perfect security in a world that constantly demands new features.

There is no such thing as perfect security.

Sure there is. An application/computer doesn't has to be insecure to work. It's just very hard to make no mistakes in complex machines and software.

Re: Pixel-perfect timing attacks with HTML5

#46

Post by tripzilch »

I have a soft spot for side-channel attacks, they are often a beautiful example of out-of-the-box thinking. This whitepaper is no exception, in particular the second part about (ab)using the SVG filters.

I was thinking, of course it doesn't help much in mitigating this attack, but they calculate average rendering times over several repeats of the same operation. When profiling performance timings, it's usually much more accurate to take the minimum execution time. The constant timing that you want to measure is part of the low-bound on the total time, any random OS process/timing glitch is going to add to that total time, but it will not somehow make the timespan you are interested in randomly run faster. There might be some exceptions to this, though (in which case I'd go for a truncated median or percentile range average or something).

Also had some ideas to improve performance on the pixel-stealing, as well as the OCR-style character reading. With the latter one could use Bayesian probabilities instead of a strict decision tree, that way it'll be more resilient to accidental timing errors so you don't need to repeat as often to ensure that every pixel is correct, just keep reading out high-entropy pixels and adjust the probabilities until there is sufficient "belief" in a particular outcome.

But as I understand from the concluding paragraphs of this paper, these vulnerabilities are already patched or very much on the way to being patched, otherwise I'd love to have a play with this :) :)

Re: Pixel-perfect timing attacks with HTML5

#47

Post by jimktrains2 »

TylerE wrote: post #21
jimktrains2 wrote: post #16

Earlier quoted context omitted.

Ah! The opinion of someone who cares nothing about the functionality of the web as a whole. JavaScript shouldn't be considered essential to use a website. If it is, the site has failed as it's job.

Not if you want to give the user decent affordances in the UI on non-HTML5 browsers.

That depends on what you mean. I _prefer_ UIs that have no Javascript on them, even since before HTML5.
Post reply on HN