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

31–40 of 47 posts

Re: Pixel-perfect timing attacks with HTML5

#31

Post by Dylan16807 »

talmand wrote: post #30
Dylan16807 wrote: post #28

Earlier quoted context omitted.

You can always turn the device off. It really is a matter of features and how they're implemented. Good luck picking a byte that can exploit a 7400.

If we're only talking about exploiting a device across a network, sure turn it off or disconnect it from the network. But there's more to security than that. One can always take the device and turn it on for oneself. If one can't exploit the device, one can resort to rubber-hose cryptanalysis.

We are only talking about exploiting a device across a network.

Re: Pixel-perfect timing attacks with HTML5

#32

Post by TeMPOraL »

Dylan16807 wrote: post #31
talmand wrote: post #30

Earlier quoted context omitted.

If we're only talking about exploiting a device across a network, sure turn it off or disconnect it from the network. But there's more to security than that. One can always take the device and turn it on for oneself. If one can't exploit the device, one can resort to rubber-hose cryptanalysis.

We are only talking about exploiting a device across a network.

Then bridge the gap by infecting pendrives. That's how e.g. Stuxnet worked.

Re: Pixel-perfect timing attacks with HTML5

#33

Post by Dylan16807 »

TeMPOraL wrote: post #32
Dylan16807 wrote: post #31

Earlier quoted context omitted.

We are only talking about exploiting a device across a network.

Then bridge the gap by infecting pendrives. That's how e.g. Stuxnet worked.

I don't understand what you're replying to. Physical access is a great way to bypass network security, but it has nothing to do with websites.

Re: Pixel-perfect timing attacks with HTML5

#34

Post by homakov »

jffry wrote: post #3

This is a fascinating attack. Definitely read the bits on the SVG filter timing attacks. They construct something that allows distinguishing black pixels from white pixels, apply a threshold filter to an iframe, and then read out pixels from the contents of that iframe. Then they turn this around, set an iframe's src to "view-source: https://example.com/" , and read out information from there (in a more efficient man…

> set an iframe's src to "view-source:https://example.com/",

is it possible to frame view-source?

Re: Pixel-perfect timing attacks with HTML5

#35

Post by kevingadd »

homakov wrote: post #34
jffry wrote: post #3

This is a fascinating attack. Definitely read the bits on the SVG filter timing attacks. They construct something that allows distinguishing black pixels from white pixels, apply a threshold filter to an iframe, and then read out pixels from the contents of that iframe. Then they turn this around, set an iframe's src to "view-source: https://example.com/" , and read out information from there (in a more efficient man…

> set an iframe's src to "view-source: https://example.com/" , is it possible to frame view-source?

It used to be possible in Chrome; I'm not sure about Firefox or modern builds of Chrome.

Re: Pixel-perfect timing attacks with HTML5

#36

Post by TeMPOraL »

Dylan16807 wrote: post #33
TeMPOraL wrote: post #32

Earlier quoted context omitted.

Then bridge the gap by infecting pendrives. That's how e.g. Stuxnet worked.

I don't understand what you're replying to. Physical access is a great way to bypass network security, but it has nothing to do with websites.

"Exploiting device across network".

Security doesn't exist in isolation. AKA. there's always a way.

Re: Pixel-perfect timing attacks with HTML5

#37

Post by Dylan16807 »

TeMPOraL wrote: post #36
Dylan16807 wrote: post #33

Earlier quoted context omitted.

I don't understand what you're replying to. Physical access is a great way to bypass network security, but it has nothing to do with websites.

"Exploiting device across network". Security doesn't exist in isolation. AKA. there's always a way.

If you assume a specific target, there is always a way to get to them.

If you're talking about making a browser secure against internet-based attacks, there is not always a way. This type of security is merely extremely, overwhelmingly difficult.

Re: Pixel-perfect timing attacks with HTML5

#38

Post by jffry »

kevingadd wrote: post #35
homakov wrote: post #34

Earlier quoted context omitted.

> set an iframe's src to "view-source: https://example.com/" , is it possible to frame view-source?

It used to be possible in Chrome; I'm not sure about Firefox or modern builds of Chrome.

Here's a test, with this markup:

http://jsfiddle.net/GEynT

  IFrame, normal
  
  IFrame, view-source
Chrome does not allow it and instead shows a blank frame. Firefox will show the view-source window inside the iframe (which probably /shouldn't/ be allowed). IE10, interestingly, loads that page, and then redirects you to view-source:http://www.example.com immediately.

Re: Pixel-perfect timing attacks with HTML5

#39

Post by jffry »

jffry wrote: post #25
randallu wrote: post #7

These same guys had previously used WebGL to suck out text in the same way; unfortunately the demo is no longer at the same URL, but it is what's responsible for the fairly weird implementation of CSS Shaders: http://www.schemehostport.com/2011/12/timing-attacks-on-css-... It's amazing that the same thing can be observed with the standard SVG software filters, though. I'd imagine that using X-Frame-Deny as they sugge…

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/

Re: Pixel-perfect timing attacks with HTML5

#40

Post by Sephr »

To mitigate the new detect visited vectors, browsers could render everything as unvisited and then asynchronously render a 'visited' overlay (in a separate framebuffer) at a later time. SVG filters will have to be processed twice for the visited-sensitive data, so a vendor may just wish to limit SVG filters to only processing the 'unvisited' framebuffer for the sake of performance.
Post reply on HN