Comment by robocat | Hacker News Reader

Comment by robocat | Hacker News Reader

Parent Full thread

The impact of this bug is probably very wide including server-side - not just a Google or Closure because as Someone1234 said: this buggy RegX was from the [RFC3986] standard on URL parsing: https://tools.ietf.org/html/rfc3986#appendix-B

Edit 3: tl;dr: [/?#\] in browsers (including backslash) ends the host/authority but the RFC only specifies [/?#] as ending characters, so for example https://xdavidhu.me\.corp.google.com/blah is recognised as host `xdavidhu.me` by the browser, and host `xdavidhu.me\.corp.google.com` by the RFC - so host name whitelisting or matching can be borked for security purposes.

Edit: maybe do a search of github for this Regexp, and see what significant finds there are. Certainly bad actors are already doing so...

Edit 2: presumably there will be a gold-rush to find other bug bounties for the same underlying issue in other software or services!

Also, Google’s $6000 payout seems extremely disappointing: Google should payout on the total impact of the bug that they measure (not just the one place he happened to find). Why should the reporter have to investigate the total impact of the bug on Google in order to get a fair payout?

On reflection: the RFC is not buggy (by definition) and the correct fix is to never whitelist a hostname that contains a backslash. There is already a large variety of other checks that should be made on hostnames (e.g. no control characters, Unicode, form, length, where .’s are, blah blah blah), so this issue should only affect poorly written code.

The “fix” made by Google to Closure is weird - because it now breaks the RFC to match the broken browser behaviour... Seems like asking for trouble (although a proper generic fix is hard). Throwing an exception on backslash seems dirty, but possibly safer...

> Also, Google’s $6000 payout seems extremely disappointing: Google should payout on the total impact of the bug that they measure (not just the one place he happened to find)

My understanding is that this is what Google's bug bounty normally does. If for example, this was trivially extentable to access to a production user, that would be the payout.

URL parsing is just a complete botch. I’m pretty surprised this sort of thing is so rare.

Most parsing in web standards is. There doesn't exist a way to validate an email address since the official spec is quite complex and then email servers can just ignore it and accept emails on addresses that shouldn't be valid.

This often becomes a pain in the ass when a single piece of software is strict on the rules that everything else ignores. Officially subdomains can't have underscores in them but the browser and everything else will allow it just fine except when you try to get a certificate and lets encrypt tells you that you have an invalid domain.

I think that's correct, or at least helpful. The business of a browser is to get data from the internet regardless of what stupid domains people use. The browser shouldn't stop you visiting an invalid url if that url will return some data. The business of Let's Encrypt is to certify the security of a domain, which includes checking if the domain is valid. LE should stop you signing an invalid URL. That is also correct.

The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible.

> The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible.

They already don't. DNS does not forbid underscores, and places hardly any restrictions on labels.

Hostnames do forbid underscores, and that muddies the water quite a bit. While disallowing A-records on labels with undersores would make sense, a CNAME on a label with an underscore can point to a domain without one, and the one it points to may or may not have an A-record.

It is really up to the client to decide that a domain name is invalid for their use case, but clients don't want to disallow something that appears to otherwise work fine. And so we end up in a situation where none of the specifications are truly followed.

This has long been known as Gresham's Law trumping Postel's Principle. For example:

* http://jdebp.uk./FGA/qmail-myths-dispelled.html#MythAboutBar...

> Also, Google’s $6000 payout seems extremely disappointing

Agree. Considering that they would probably make this money under a microsecond they could pay a generous reward. The impact is large though the bug is present in a single line of code.

$6,000 per microsecond would be $6Bn per second, big and profitable as Google is, i'm going to say it's a little bit less than that :)

>Google should payout on the total impact of the bug that they measure

And what is that total impact?

As said: only Google has the resources and motivation to measure the potential impact. David already identified a few places the bug might affect:

“I found this regex in the Google Cloud Console’s JS, Google Actions Console’s JS, in YouTube Studio, in myaccount.google.com (!) and even in some Google Android Apps. A day later I even found this line in the Google Corp Login Page (login.corp.google.com)”.

>only Google has the resources and motivation to measure the potential impact.

And apparently they have judged the impact less than folks who think $6000 is too small.

They may have decided, for example, that the majority of cases were not security related. If they were just cosmetic or something...

One way to estimate it is to ask how much that bug would've sold for on the black market.

That'd definitely be more than USD 6k.

Who would the buyer be and how much would they pay?

Reply on news.ycombinator.com