Live data from Hacker News

Blizzard games were vulnerable to DNS rebinding attack

bugs.chromium.org

71–80 of 94 posts

Re: Blizzard games were vulnerable to DNS rebinding attack

#71
post #10

Earlier quoted context omitted.

Can you explain why this is a Chrome-specific issue? I believe that it applies to all web browsers, including Internet Explorer for UNIX (which I do have access to and I can test if you would like me to confirm). I remember this being a vulnerability class with CUPS, which listens on http://localhost:631/ , about 10 years ago. In particular, note that the request is not made to localhost, it's made to a DNS name that…

How about caching a DNS result for the duration of a tab? Doesn't solve everything but probably good enough. I don't think it'd break many things (sure it may affect some round robin DNS things for long-open pages that are Ajax'ing back home frequently, but that should be minimal)

Gmail is not minimal.

There is no quick fix for this.

Re: Blizzard games were vulnerable to DNS rebinding attack

#72
post #44

Earlier quoted context omitted.

That's how it should be done yeah. Developers on Windows seem to be really loose in their use of TCP or UDP for IPC. Even my mouse driver opens up a port on 0.0.0.0.

UDP for IPC seems to be especially crazy to me. I mean sending data over TCP to localhost is basically a memcpy(), what advantages could UDP possibly have in that context?

Guarantee of preserved message boundaries? It’s the reason Unix domain sockets have SOCK_SEQPACKET and Windows named pipes have message mode.

Re: Blizzard games were vulnerable to DNS rebinding attack

#73
post #11

Developer 101: if you want to do a blacklist, do a whitelist instead.

Developer 102 (or perhaps entrance exam): Never return authorization credentials on an unauthenticated HTTP endpoint.

It says Authorization, but this is really more of an anti-CSRF token, not an actual authorization credential, and anti-CSRF tokens are completely legitimate to return over an unauthenticated HTTP endpoint.

Re: Blizzard games were vulnerable to DNS rebinding attack

#74
post #5

So basically this is a local web server that is used for IPC? Is there a reason to do local IPC over TCP/IP, rather than over named pipes / unix pipes, other than not knowing about the existence of named pipes / unix pipes?

At least on Windows, TCP performs better than named pipes.

Re: Blizzard games were vulnerable to DNS rebinding attack

#75
post #38

Earlier quoted context omitted.

Agreed. Not that lost ago, there was a post about how a BitTorrent client had a similar issue. Just like in that case, the real vulnerability was in browsers. I wonder how many programs are going to be discovered to be “vulnerable” before people realize that they are missing the point.

What do you think browsers should do instead?

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

Re: Blizzard games were vulnerable to DNS rebinding attack

#76

Earlier quoted context omitted.

Agreed. Not that lost ago, there was a post about how a BitTorrent client had a similar issue. Just like in that case, the real vulnerability was in browsers. I wonder how many programs are going to be discovered to be “vulnerable” before people realize that they are missing the point.

The vulun is in the fact that the program blindly trusts incoming HTTP based only on a nonce being in both the body and a header.

No, the "vuln" is assuming that only users on the machine can access localhost. This is a completely reasonable assumption, and it is on the browsers for invalidating it.

Re: Blizzard games were vulnerable to DNS rebinding attack

#77
post #60

Earlier quoted context omitted.

Could someone explain in the most accessible language, how a problem like this could even be fixed?

Answer: The service should check that the `Host` header on every request specifies `localhost`, `127.0.0.1`, or whatever other name is normally used to access it. If the `Host` header specifies a possibly-attacker-controlled name, the service should reject the request. Explanation: The problem is that the service is relying on same-origin policy to prevent a web site running in a local browser from making requests to…

And/or simply implement CORS headers.

Re: Blizzard games were vulnerable to DNS rebinding attack

#78
post #38

Earlier quoted context omitted.

What do you think browsers should do instead?

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

I call BS, it's the responsibility of the server to check Host headers and implement CORS. All browser provide these security measurements. There are valid use cases for having domain aliases for local ips.

Re: Blizzard games were vulnerable to DNS rebinding attack

#79

Earlier quoted context omitted.

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

I call BS, it's the responsibility of the server to check Host headers and implement CORS. All browser provide these security measurements. There are valid use cases for having domain aliases for local ips.

> There are valid use cases for having domain aliases for local ips.

My preferred solution doesn't prevent this, and in fact it is preferred partially because some of the other solutions do.

Re: Blizzard games were vulnerable to DNS rebinding attack

#80
post #38

Earlier quoted context omitted.

What do you think browsers should do instead?

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

That doesn't save you from this attack - you can send the index page and some JS over with a long Cache-Control header, and then trigger the site to get loaded some days later when DNS has been changed to point to localhost. The JS will trigger the same XHR and it will succeed this time.

(.. and now that I think about caching, the various "within the same tab" solutions elsewhere in the comments don't work, because they'd force Gmail / OWA / Slack / etc. to get reloaded with a full cache flush when they change IP addresses, which everyone would hate.)

Post reply on HN