5 ms·

Ring-Road Bug

47 points by r721 10y ago

r721 10y ago
Purdue CERIAS Researchers Find Vulnerability in Google Protocol https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/ https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r...
pfooti 10y ago
I don't get it. The vulnerability sounds like the cyphertext having the same length as the plain text in transit, but then they go on to say they were able to attack 1 in 10 Gmail users with their attack? I must be misreading it. Maybe 1 in 10 Gmail users is on QUIC?
- Boxbot 10y ago
  Probably something like 1 in 10 of the Gmail users examined have weak / short enough passwords that by knowing the length the dictionary used becomes small enough that a brute force attack becomes feasible.
  - tyingq 10y ago
    The other link posted here confirms they use the length to select popular passwords of that length. See "step 2": http://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol http://www.cerias.purdue.edu/site/blog/post/purdue_cerias_re... It doesn't say how they get the Gmail address to correlate back to the known length password though. I see the "light on details" reasoning, but it doesn't go well with the sensationalist "1 in 10 Gmail users." Surely Google doesn't allow high rate guessing, they must throttle or temporarily disable targeted accounts.
  - Buge 10y ago
    That doesn't really make sense. Gmail has a minimum password length of 8 characters. I bet 50% of users have an 8 character password. This bug hardly gives you any information at all.
  - eh78ssxv2f 10y ago
    Since gmail has minimum password length of 8, my random guess is that 90% of the users have passwords between 8 and 15. Does knowing the precise length of the password buys the attacker so much that they can now guess the passwords of 10% users? Also, note that they do not know the username that corresponds to the given password length. Without more details, I seriously doubt this claim.
pbnjay 10y ago
It's certainly not good to leak this information, but wouldn't most of the providers mentioned have an automatic lockout for repeated login attempts? How could an attacker actually exploit this in any non-trivial system? This is much more dangerous if combined with a database dump containing password hashes. (but that's a different problem) It's cool as an undergraduate student project, but until it's got a CVE assigned and/or better vetting I don't think it's very helpful to be sharing a FUD site like this.
userbinator 10y ago
Knowing the length of the password in theory makes it weaker, but in practice, it doesn't if your password is already longer than feasibly bruteforceable.
- mikeash 10y ago
  For all possible passwords up to and including length n (in bytes), nearly 255/256 of them are exactly length n, and only slightly more than 1/256 of them are shorter than n. Information leakage is never desirable, but knowing the length should never make the difference between a password being crackable or not. This seems like a "huh, should fix that in the next version if we don't have anything better to do" bug, rather than a "buy a domain name and alert the world" bug.
  - foota 10y ago
    I think the author's idea is that it allows for easy detection of accounts that can be trivially compromised.
    - mikeash 10y ago
      Like, this account has a password length of 4, so attack that? Makes some sense. Although if it truly is 1 in 10 accounts, you could just attack them all this way, and go with the 10% that succeed.
      - foota 10y ago
        That's true. 1 in 10 does surprise me. I'm also curious where they got this traffic data from?
      - stouset 10y ago
        It's even worse — you've correlated a particular IP origin to a weak password. Now you still have to figure out the account to even begin guessing. I guess this is the flip side to marketing of bugs like Heartbleed. Now people are starting to use the same approach for trivial nonsense.
weavejester 10y ago
Slightly off-topic, but the traffic sign on the site is one warning of a roundabout, rather than a ring-road.
niftich 10y ago
Both the site and the blog post are devoid of good information, like an explanation of the exact design issues in the affected protocols where this effect occurs. I would've liked to see that. In either case, TLS does this too [1], so the mitigations they recommend will have no effect. Worth reading cryptographer Thomas Pornin's opinion of the matter [2] in response to that thread. [1] https://security.stackexchange.com/questions/109973/ https://security.stackexchange.com/questions/109973/ [2] https://security.stackexchange.com/a/109976 https://security.stackexchange.com/a/109976
- userbinator 10y ago
  I'll quote the last sentence of his post since I think it's the strongest argument to why this is not a particularly interesting security issue: A realistic answer would be to point out that if leaking the password length allows breaking it, then this is a poor password to begin with, and you should probably fix that. (Aside: I wonder how many systems have censored Pornin's last name.)
  - deleted 10y ago
    [deleted]
zerocrates 10y ago
The page is oddly written in a variety of ways: "The team was astonished," the insistence on "G-mail," and what is this doing in there: "Apple has decided to use alternatives such as Advanced Encryption Standard, Cipher Block Chaining (AES-CBC) + Keyed Hash Authentication (HMAC) to achieve both confidentiality and integrity for sensitive data transmitted over the Internet." They're talking about a vulnerability in QUIC, a protocol Apple doesn't support, to my knowledge. To the extent that eyebrows are waggled in the direction of AES-GCM in TLS, Apple supports that as well. "AES-GCM is also used by TLS version 1.2. We have been unable to verify the Ring-Road vulnerability in TLS due to time constraints, but we strongly encourage other researchers to study TLS version 1.2 to see if Ring-Road exists." Is this the same thing as what somebody previously called the "bicycle attack"? [1] (it went over like a lead balloon so you're forgiven for not having noticed) [1] https://guidovranken.wordpress.com/2015/12/30/https-bicycle-attack/ https://guidovranken.wordpress.com/2015/12/30/https-bicycle-...
ecma 10y ago
I'm dumbfounded finding this link on the top page. In news today, we found out that stream ciphers retain [zp]text length and unpadded form data is insecure. The nuance which seems to be missing in the understanding is that TLS confidentiality never intended (AFAIK) to include plaintext size. If it did, there would be a very interesting tradeoff around on-wire size and size masking. Even so, random per-message padding with known (e.g. protocol defined) bounds could be defeated by capturing multiple/many valid authentication packets or whatever the target is. The only (but still important) lesson here is to pad critical form data as a site owner (assuming randomness doesn't buy you much) or have a good user password such that knowing the length doesn't make brute achievable. Even do a pre-hashing step on the client if you can guarantee it will happen and care to do so. I'm sure smarter people than me have given good advice about this somewhere. The most frustrating thing about this is the presumption to name something like this. Bug names have always bugged me (hah) but this is a bit absurd. It doesn't even seem that clever :/
modeless 10y ago
They advise switching to TLS even though it probably has the issue too and they just didn't bother to check? That's highly irresponsible. If a bunch of ill-informed sysadmins start using this as an excuse to block QUIC it will be a step backwards for the internet. Given the nature of a length disclosure vulnerability, it should be trivial to mitigate client side, which means that any particular site can be patched instantly, if the vulnerability actually exists. If this was actually serious, and was disclosed responsibly, then large sites would already be fixed. Without relevant details this site reads more like an ad for this "Spotlight Cybersecurity" outfit than anything else. I'm guessing the real story is a lot different than what's presented here.
anon263626 10y ago
UDP shouldn't be used for content traffic, it has no guarantees. Plus, this is what happens when reinventing emperors new clothes protocols... greater attack surface for marginal benefit.
- IshKebab 10y ago
  QUIC doesn't just send data straight over UDP without making sure it arrives. You should probably at least vaguely understand how it works before criticising it.
  - anon263626 10y ago
    I wrote and maintained an IP/UDP stack for an expensive, reliable, industrial packet radio, so you should back off your presumptive, elitist tone. Sure, they maintain a control TCP channel like ftp but that's a normal pattern. Falling back to other protocols is a necessity because some environments literally lock down everything apart from ARP, DHCP, DNS, HTTP/S and email. Writing an application-level protocol to make UDP act like TCP or SCTP is a sign of failure to fix issues lower down. Worse, UDP often gets dropped first when a network is saturated, and it's harder troubleshoot to because it's not connection-oriented stateful and doesn't work with existing tools... debugging now requires nonstandard knowledge inside an app. (Turning a browser into an OS is a metastasizing cancer.) There are better ways to solve efficient, low-latency content distribution and bidirectional state RPC without reinventing everything every other year.
hannob 10y ago
Sorry, but this is ridiculously bad. So the point here is that they say QUIC doesn't do length hiding. Okay. This is not a secret, but okay, you can point that out. However then they go on that they don't know (because they haven't checked) whether the same is true for TLS. It is. It's been published as the HTTPS Bicycle attack. Writing "we strongly encourage other researchers to study TLS version 1.2 to see if Ring-Road exists" is comical under this circumstances. The university's press release tries to spin this as a google bug: https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/ https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r... Which is... quite a stretch, given that QUIC just has the very same behavior as TLS. It almost makes you think they haven't checked TLS to be able to spin this as a "google vuln" story. Then they recommend to disable QUIC. Which will do... nothing to mitigate this vuln, because of course the browser will just fall back to normal HTTPS with TLS - which has the same vuln, but hey, they haven't checked.
erpellan 10y ago
This looks like a childish attempt to drive traffic to their consulting site, which itself looks like it was put together as part of a class project. Half the links on it go nowhere.

47 points by r721 10y ago

r721 10y ago

Purdue CERIAS Researchers Find Vulnerability in Google Protocol https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/ https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r...

pfooti 10y ago

I don't get it. The vulnerability sounds like the cyphertext having the same length as the plain text in transit, but then they go on to say they were able to attack 1 in 10 Gmail users with their attack? I must be misreading it. Maybe 1 in 10 Gmail users is on QUIC?

Boxbot 10y ago
Probably something like 1 in 10 of the Gmail users examined have weak / short enough passwords that by knowing the length the dictionary used becomes small enough that a brute force attack becomes feasible.
- tyingq 10y ago
  The other link posted here confirms they use the length to select popular passwords of that length. See "step 2": http://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol http://www.cerias.purdue.edu/site/blog/post/purdue_cerias_re... It doesn't say how they get the Gmail address to correlate back to the known length password though. I see the "light on details" reasoning, but it doesn't go well with the sensationalist "1 in 10 Gmail users." Surely Google doesn't allow high rate guessing, they must throttle or temporarily disable targeted accounts.
- Buge 10y ago
  That doesn't really make sense. Gmail has a minimum password length of 8 characters. I bet 50% of users have an 8 character password. This bug hardly gives you any information at all.
- eh78ssxv2f 10y ago
  Since gmail has minimum password length of 8, my random guess is that 90% of the users have passwords between 8 and 15. Does knowing the precise length of the password buys the attacker so much that they can now guess the passwords of 10% users? Also, note that they do not know the username that corresponds to the given password length. Without more details, I seriously doubt this claim.

pbnjay 10y ago

It's certainly not good to leak this information, but wouldn't most of the providers mentioned have an automatic lockout for repeated login attempts? How could an attacker actually exploit this in any non-trivial system? This is much more dangerous if combined with a database dump containing password hashes. (but that's a different problem) It's cool as an undergraduate student project, but until it's got a CVE assigned and/or better vetting I don't think it's very helpful to be sharing a FUD site like this.

userbinator 10y ago

Knowing the length of the password in theory makes it weaker, but in practice, it doesn't if your password is already longer than feasibly bruteforceable.

mikeash 10y ago
For all possible passwords up to and including length n (in bytes), nearly 255/256 of them are exactly length n, and only slightly more than 1/256 of them are shorter than n. Information leakage is never desirable, but knowing the length should never make the difference between a password being crackable or not. This seems like a "huh, should fix that in the next version if we don't have anything better to do" bug, rather than a "buy a domain name and alert the world" bug.
- foota 10y ago
  I think the author's idea is that it allows for easy detection of accounts that can be trivially compromised.
  - mikeash 10y ago
    Like, this account has a password length of 4, so attack that? Makes some sense. Although if it truly is 1 in 10 accounts, you could just attack them all this way, and go with the 10% that succeed.
    - foota 10y ago
      That's true. 1 in 10 does surprise me. I'm also curious where they got this traffic data from?
    - stouset 10y ago
      It's even worse — you've correlated a particular IP origin to a weak password. Now you still have to figure out the account to even begin guessing. I guess this is the flip side to marketing of bugs like Heartbleed. Now people are starting to use the same approach for trivial nonsense.

weavejester 10y ago

Slightly off-topic, but the traffic sign on the site is one warning of a roundabout, rather than a ring-road.

niftich 10y ago

Both the site and the blog post are devoid of good information, like an explanation of the exact design issues in the affected protocols where this effect occurs. I would've liked to see that. In either case, TLS does this too [1], so the mitigations they recommend will have no effect. Worth reading cryptographer Thomas Pornin's opinion of the matter [2] in response to that thread. [1] https://security.stackexchange.com/questions/109973/ https://security.stackexchange.com/questions/109973/ [2] https://security.stackexchange.com/a/109976 https://security.stackexchange.com/a/109976

userbinator 10y ago
I'll quote the last sentence of his post since I think it's the strongest argument to why this is not a particularly interesting security issue: A realistic answer would be to point out that if leaking the password length allows breaking it, then this is a poor password to begin with, and you should probably fix that. (Aside: I wonder how many systems have censored Pornin's last name.)
- deleted 10y ago
  [deleted]

zerocrates 10y ago

The page is oddly written in a variety of ways: "The team was astonished," the insistence on "G-mail," and what is this doing in there: "Apple has decided to use alternatives such as Advanced Encryption Standard, Cipher Block Chaining (AES-CBC) + Keyed Hash Authentication (HMAC) to achieve both confidentiality and integrity for sensitive data transmitted over the Internet." They're talking about a vulnerability in QUIC, a protocol Apple doesn't support, to my knowledge. To the extent that eyebrows are waggled in the direction of AES-GCM in TLS, Apple supports that as well. "AES-GCM is also used by TLS version 1.2. We have been unable to verify the Ring-Road vulnerability in TLS due to time constraints, but we strongly encourage other researchers to study TLS version 1.2 to see if Ring-Road exists." Is this the same thing as what somebody previously called the "bicycle attack"? [1] (it went over like a lead balloon so you're forgiven for not having noticed) [1] https://guidovranken.wordpress.com/2015/12/30/https-bicycle-attack/ https://guidovranken.wordpress.com/2015/12/30/https-bicycle-...

ecma 10y ago

I'm dumbfounded finding this link on the top page. In news today, we found out that stream ciphers retain [zp]text length and unpadded form data is insecure. The nuance which seems to be missing in the understanding is that TLS confidentiality never intended (AFAIK) to include plaintext size. If it did, there would be a very interesting tradeoff around on-wire size and size masking. Even so, random per-message padding with known (e.g. protocol defined) bounds could be defeated by capturing multiple/many valid authentication packets or whatever the target is. The only (but still important) lesson here is to pad critical form data as a site owner (assuming randomness doesn't buy you much) or have a good user password such that knowing the length doesn't make brute achievable. Even do a pre-hashing step on the client if you can guarantee it will happen and care to do so. I'm sure smarter people than me have given good advice about this somewhere. The most frustrating thing about this is the presumption to name something like this. Bug names have always bugged me (hah) but this is a bit absurd. It doesn't even seem that clever :/

modeless 10y ago

They advise switching to TLS even though it probably has the issue too and they just didn't bother to check? That's highly irresponsible. If a bunch of ill-informed sysadmins start using this as an excuse to block QUIC it will be a step backwards for the internet. Given the nature of a length disclosure vulnerability, it should be trivial to mitigate client side, which means that any particular site can be patched instantly, if the vulnerability actually exists. If this was actually serious, and was disclosed responsibly, then large sites would already be fixed. Without relevant details this site reads more like an ad for this "Spotlight Cybersecurity" outfit than anything else. I'm guessing the real story is a lot different than what's presented here.

anon263626 10y ago

UDP shouldn't be used for content traffic, it has no guarantees. Plus, this is what happens when reinventing emperors new clothes protocols... greater attack surface for marginal benefit.

IshKebab 10y ago
QUIC doesn't just send data straight over UDP without making sure it arrives. You should probably at least vaguely understand how it works before criticising it.
- anon263626 10y ago
  I wrote and maintained an IP/UDP stack for an expensive, reliable, industrial packet radio, so you should back off your presumptive, elitist tone. Sure, they maintain a control TCP channel like ftp but that's a normal pattern. Falling back to other protocols is a necessity because some environments literally lock down everything apart from ARP, DHCP, DNS, HTTP/S and email. Writing an application-level protocol to make UDP act like TCP or SCTP is a sign of failure to fix issues lower down. Worse, UDP often gets dropped first when a network is saturated, and it's harder troubleshoot to because it's not connection-oriented stateful and doesn't work with existing tools... debugging now requires nonstandard knowledge inside an app. (Turning a browser into an OS is a metastasizing cancer.) There are better ways to solve efficient, low-latency content distribution and bidirectional state RPC without reinventing everything every other year.

hannob 10y ago

Sorry, but this is ridiculously bad. So the point here is that they say QUIC doesn't do length hiding. Okay. This is not a secret, but okay, you can point that out. However then they go on that they don't know (because they haven't checked) whether the same is true for TLS. It is. It's been published as the HTTPS Bicycle attack. Writing "we strongly encourage other researchers to study TLS version 1.2 to see if Ring-Road exists" is comical under this circumstances. The university's press release tries to spin this as a google bug: https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/ https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r... Which is... quite a stretch, given that QUIC just has the very same behavior as TLS. It almost makes you think they haven't checked TLS to be able to spin this as a "google vuln" story. Then they recommend to disable QUIC. Which will do... nothing to mitigate this vuln, because of course the browser will just fall back to normal HTTPS with TLS - which has the same vuln, but hey, they haven't checked.

erpellan 10y ago

This looks like a childish attempt to drive traffic to their consulting site, which itself looks like it was put together as part of a class project. Half the links on it go nowhere.