Ring-Road Bug | Hacker News Reader

Ring-Road Bug

ringroadbug.com

47 pointsr72128 comments

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

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/ [2] https://security.stackexchange.com/a/109976

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

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

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

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.

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?

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.

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

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.

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.

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

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.

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.

I think the author's idea is that it allows for easy detection of accounts that can be trivially compromised.

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.

That's true. 1 in 10 does surprise me. I'm also curious where they got this traffic data from?

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.

True, but it might not be that hard to find a user's gmail address given network access. For instance you could get it off a site where the user's email address is sent over http.

Agreed, but the level of self-inflation around the severity around this "bug" is shameful.

I am assuming that if somebody tries to brute-force Gmail login form, eventually Google will start throttling the login attempts. I am curious about how they got around that. Getting around the throttling seems like a more concerning bug to me (if they were ever able to do that).

It's also not clear how they know which account goes with the password they are trying to guess.

Purdue CERIAS Researchers Find Vulnerability in Google Protocol

https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r...

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.

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.

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.

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.

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.

Reply on news.ycombinator.com