
Ring-Road Bug - r721
http://www.ringroadbug.com/
======
hannob
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...](https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/)

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.

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

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

------
zerocrates
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-...](https://guidovranken.wordpress.com/2015/12/30/https-bicycle-
attack/)

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

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

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

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

------
userbinator
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
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
I think the author's idea is that it allows for easy detection of accounts
that can be trivially compromised.

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

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

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

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

------
r721
Purdue CERIAS Researchers Find Vulnerability in Google Protocol

[https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_r...](https://www.cerias.purdue.edu/site/blog/post/purdue_cerias_researchers_find_vulnerability_in_google_protocol/)

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

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

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

