Weekly Edition
Return to the Security page
| |||||||||||||
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost)
Threatpost is reporting on a browser vulnerability that affects secure cookies when TLS or SPDY compression is supported. Researchers Juliano Rizzo and Thai Duong, who also discovered the BEAST flaw, have called the new vulnerability "Compression Ratio Info-leak Made Easy" or CRIME. "Rizzo said that browsers that implement either TLS or SPDY compression are known to be vulnerable. That includes Google Chrome and Mozilla Firefox, as well as Amazon Silk. But the attack also works against several popular Web services, such as Gmail, Twitter, Dropbox and Yahoo Mail. SPDY is an open standard developed by Google to speed up Web-page load times and often uses TLS encryption.
[...]
Google and Mozilla have developed patches to defend against the CRIME attack, Rizzo said, and the latest versions of Chrome and Firefox are protected. The researchers will present their results at Ekoparty next week." Some speculation on the details can be found at Stack Exchange.
(Log in to post comments)
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 13, 2012 18:48 UTC (Thu) by butlerm (subscriber, #13312) [Link]
How does the attacker get the size of the compressed data without packet sniffing on the client? And presumably the only way to packet sniff on the client is already to have made a root level compromise.
But if you have a root level compromise, you could presumably capture the actual keystrokes or even read the decrypted cookie out of the browser memory. No?
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 13, 2012 21:03 UTC (Thu) by intgr (subscriber, #39733) [Link] > How does the attacker get the size of the compressed data without packet sniffing on the client
IP networks are very vulnerable in general. That's the threat model TLS is supposed to protect against -- it establishes a secure channel over an insecure network.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 13, 2012 21:06 UTC (Thu) by intgr (subscriber, #39733) [Link]
> being in the same network segment as a router
Sorry, that was misleading. I meant any Ethernet segment where the traffic passes through, such as your office network or an Internet exchange point.
> haging access
Should be "having access"
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 13, 2012 22:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> > being in the same network segment as a router
>Sorry, that was misleading. I meant any Ethernet segment where the traffic passes through, such as your office network or an Internet exchange point.
actually, this isn't enough by itself nowdays.
With most of the ethernet infrastructure being switches, you will only occasionally see packets destined for other systems.
You can start playing games with ARP to try and route all traffic on the network through your machine instead of the router it is supposed to go through, but this sort of thing tends to cause other problems, so it's far from stealthy.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 10:09 UTC (Fri) by paulj (subscriber, #341) [Link]
Many "ethernet" segments these days are shared Wifis - inherently a multi-access medium.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 15, 2012 23:44 UTC (Sat) by cmccabe (guest, #60281) [Link]
Most (though not all) wifi is encrypted these days.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 20, 2012 22:01 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> Most (though not all) wifi is encrypted these days.
Wifi does not encrypt the size of the packets.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 13, 2012 21:13 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Also the size and location of the plaintext in the encrypted data is public information, the attacker can make their own requests and measure where in the response the session cookies and whatnot are stored and apply that knowledge to another encrypted session.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 0:19 UTC (Fri) by butlerm (subscriber, #13312) [Link]
>By having access to any intermediate node/router between the client and the server -- your ISP or government could easily do it.
Okay, so now your ISP or government has to be motivated enough to capture your traffic, and then somehow entice you to visit a specific web page while you have a secure session open to the target site, on the same browser. That is doable, I suppose, if you are desperate enough.
Speaking of which, whatever motivated Microsoft to make all browser windows operate in the same session context in the first place? Chrome used to correctly operate with separate sessions for separately created tabs or window groups, but then they changed to have shared sessions like Microsoft.
That is the _real_ cause of this browser vulnerability. If the browser manufacturers didn't share private data across what ought to be separate sessions, it would be impossible to implement a chosen plaintext attack on the session cookie from other random web pages in the first place.
>Or even anyone with a BGP router could force the Internet to route and hijack certain traffic through them, like when Pakistan took down YouTube all over the world.
"Anyone" with a BGP router cannot do this kind of thing. You have to have unfiltered BGP access, which any sane transit provider will only provide to other major transit providers - meaning Tier 1 and Tier 2 ISPs. Of course we are more or less completely vulnerable to them.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 0:40 UTC (Fri) by intgr (subscriber, #39733) [Link]
> and then somehow entice you to visit a specific web page while you have a secure session open to the target site, on the same browser
It's actually easier than that. When you visit *any* HTTP (non-secure) site, they can inject the necessary JavaScript code to carry out the attack.
> If the browser manufacturers didn't share private data across what ought to be separate sessions
Agreed. Personally I'd prefer restricting or policing how cross-domain requests are authenticated -- that would address many other attacks, too.
> "Anyone" with a BGP router cannot do this kind of thing
Right you are, but that's still way too many people and organizations to trust.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 5:46 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>"Anyone" with a BGP router cannot do this kind of thing. You have to have unfiltered BGP access, which any sane transit provider will only provide to other major transit providers - meaning Tier 1 and Tier 2 ISPs. Of course we are more or less completely vulnerable to them.
Oh, but there are SO many insane transit providers.
I was shocked once that our stub AS was not filtered at one of our upstream. I've checked - my bogus announcement propagated as far as AMS-IX, so I could (in theory) cause a major Internet disruption in Europe with only few lines of configuration.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 9:35 UTC (Fri) by paulj (subscriber, #341) [Link] You have to have unfiltered BGP access, which any sane transit provider will only provide to other major transit providers........ Sorry, I need a few more seconds to compose myself, stop rolling on the floor laughing, and get back on my chair before I can reply. ;) Two problems: 1. You're assuming that the internet has clear borders between "anyone with a BGP router" and "major transit providers". You're assuming it is difficult for anyone in the out-set to persuade anyone in the in-set to let them in. Bear in mind some parts of the "transit provider" set can be large clusters of quite small players (sometimes literally 1-man operations). Bear in mind the internet has been growing at a good pace, and is likely to continue to grow for some time, and that many in the "transit provider" set have a business model that depends on that growth happening. 2. Ignoring point 1, taking it as given a clear delineation criteria between the transit ASes and the edges (clear from the POV of the transit providers), and a transit provider set which are *all* strongly motivated to exclude any new entrants: You're assuming that a large percentage of transit providers are both, a) technically competent at specifying filters b) have a clear financial motivation to spend their resources on implementing operational processes to ensure new non-transit customers will consistently have filters applied. Even if the vast majority of transit providers meet assumption a (and it's not clear that's the case ☺), assumption b doesn't hold for most (at least, it's not immediately obvious to them). So, there isn't really a great pressure on them to reliably implement these filters, and so often they don't (because they generally don't, or because their processes aren't rigorous enough to ensure they reliably do).
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 14, 2012 10:00 UTC (Fri) by paulj (subscriber, #341) [Link]
Edit: s/*all* strongly motivated to exclude any new entrants/*none* have a financial motivation to include new entrants/
(if they have a motivation to exclude then 2b clearly becomes true, oops ;) ).
Editing posts.. Posted Sep 14, 2012 10:17 UTC (Fri) by geertj (subscriber, #4116) [Link]
A request to our grumpy editor: will we see editing of comments for spelling/other mistakes in the site at some point? It's pretty annoying to see these correction posts (and i've had to do those myself as well in the past).
Editing posts.. Posted Sep 14, 2012 10:52 UTC (Fri) by hummassa (subscriber, #307) [Link]
Facebook solved the "historical revisionism" problem with editing in a really nice way: if you edit a post, the old version is just invisible, and it's still accessible via a "edited/show edition history" button/link.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 16, 2012 8:34 UTC (Sun) by butlerm (subscriber, #13312) [Link]
>So, there isn't really a great pressure on them to reliably implement these filters, and so often they don't (because they generally don't, or because their processes aren't rigorous enough to ensure they reliably do).
The original poster claimed that "anyone with a BGP router" could do this, which is clearly not the case. One would hope that the various attempts to secure BGP route advertisements would have born some fruit by now, but apparently that isn't the case either.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 16, 2012 18:16 UTC (Sun) by paulj (subscriber, #341) [Link]
Well, I was replying to the person who was claiming the other extreme, that such announcements required a kind of BGP connection that was very hard to obtain. Which is not the case. I did not argue that "anyone with a BGP router" could do it, however there are no real obstacles, other than needing a relatively small amount of money and perhaps a little time, to acquiring the capability.
Work to secure the BGP protocol is still quite a way away from being finished, never mind deployed.
CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost) Posted Sep 18, 2012 17:34 UTC (Tue) by paulj (subscriber, #341) [Link]
Oh, another factor to consider is that you don't actually need to own a BGP router, in the legal sense. You just need control of it. Major router vendor control plane software is not immune to being 0wned...
Any server-side defenses? Posted Sep 13, 2012 21:12 UTC (Thu) by kmself (subscriber, #11565) [Link]
I've confirmed that we're NOT employing SSL compression locally, and I'v inquired with our load balancer (we terminate SSL on the LB) vendor regarding updates (they're unaware of the issue yet).
That said: is this an attack which can be addressed on the server side, or does it depend on client-side updates as mentioned in the article?
Any server-side defenses? Posted Sep 13, 2012 21:26 UTC (Thu) by cyanit (guest, #86671) [Link]
The server chooses whether to use compression in the ServerHello, so it should be possible to have the server avoid requesting compression at all.
Some non-compliant clients might perhaps not like it though, not sure.
Of course, this is suboptimal compared to the client avoiding compression of sensitive parts, but I'm not sure how the server could detect that the client is fixed.
Maybe the TLS standard should be amended to add new compression algorithm identifiers that tell the server that the client knows to securely compress HTTP requests.
Different compression scheme Posted Sep 14, 2012 13:24 UTC (Fri) by epa (subscriber, #39769) [Link]
Any sliding window compression scheme - indeed, any compression scheme at all which adapts to the input data - has this problem that if you can control what comes before or after the secret text, you can infer things about the secret text from the length of the resulting message.
For applications like SSL headers where the content must be kept secret but saving bandwidth is still important, a simple Huffman code with fixed weights could be used instead. In other words somebody analyses typical traffic to find the frequency of each byte value, and these frequencies are then hardcoded in the compressor and decompressor. This would still save a lot of bandwidth but would not have this class of vulnerability. It also requires less memory for compression and decompression, which I guess might still matter if you have thousands of incoming connections.
Different compression scheme Posted Sep 20, 2012 5:45 UTC (Thu) by alonz (subscriber, #815) [Link] Another option is to reset the compression state between the headers and payload (I know many compression schemes have a special control code to do this — unfortunately I don't know if SSL/TLS compression does).
Different compression scheme Posted Sep 20, 2012 11:43 UTC (Thu) by epa (subscriber, #39769) [Link]
Here I think the attacker can add things to the headers, such as cookies or the exact path being requested. So you would need to reset the compression state between one header line and the next.
|
|||||||||||||