Live data from Hacker News

Blizzard games were vulnerable to DNS rebinding attack

bugs.chromium.org

11–20 of 94 posts

Re: Blizzard games were vulnerable to DNS rebinding attack

#12

The vulnerable update daemon is running all of the time if you've installed any Blizzard game in the past, not just if you currently play Blizzard games?

I believe they've patched it already. But if you haven't updated the updater yet, you're probably still vulnerable.

Re: Blizzard games were vulnerable to DNS rebinding attack

#14
post #6
post #3

the DNS rebinding vulnerability exists in applications other than Blizzard games, such as this one in Bittorrent Transmission also reported by Tavis Ormandy.... https://github.com/transmission/transmission/pull/468 Seems to be a quite prevalent issue...

That's because for decades binding to localhost has been taken to mean "only users on the local machine can access this". Now chrome is breaking that assumption through a leaky sandbox, and demanding everyone else change rather than fixing their own security issues.

[deleted]

Re: Blizzard games were vulnerable to DNS rebinding attack

#15
post #10
post #6

Earlier quoted context omitted.

That's because for decades binding to localhost has been taken to mean "only users on the local machine can access this". Now chrome is breaking that assumption through a leaky sandbox, and demanding everyone else change rather than fixing their own security issues.

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…

Hopefully not, that will make local development very hard. Maybe an opt-out for it though, heh

Re: Blizzard games were vulnerable to DNS rebinding attack

#16
post #2

Disappointing (lack of) response/fix Would have assumed they'd do better given how polished their consumer products are

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

It looks like is an HTTP API server that's only intended to be used by other programs on the local machine that explicitly know about it, not by any HTTP client that happens to run on the local machine (like a web browser, or an embedded web browser in some random app). They appear to have an authentication step by having the first URL return a token, and requiring you pass the token to all other URLs, but that doesn't actually secure anything.

The easy way to fix it is to introduce some non-HTTP-based way of transmitting this token. For instance, put the token in the user's Blizzard settings directory, so that you have to have read access to the user's files to access the server. Or use some non-network-based interprocess communication mechanism, like named pipes, to do the initial authentication. Or (what we did a couple jobs ago), check what the other end of the socket is, and make sure it's a known-good app (instead of making sure it's not a known-bad app, which is what they're doing).

If you're intentionally embedding a web browser in your app and want it to access this interface, you can have your code pick up the token from a file / from IPC using native code, and then send it into the embedded web browser as a cookie or JavaScript variable or something. Most ways of embedding a web browser in a native app support this.

The reason they fixed it this way is probably because all good ways of fixing it require code changes to every client to use the new mechanism, and there are lots of clients using this interface, and this only requires a code change to the one server. (Even though "client" and "server" are both running on the same machine, patching one binary on everyone's computer is still easier than rebuilding and patching lots of binaries.)

Re: Blizzard games were vulnerable to DNS rebinding attack

#17
post #12

The vulnerable update daemon is running all of the time if you've installed any Blizzard game in the past, not just if you currently play Blizzard games?

I believe they've patched it already. But if you haven't updated the updater yet, you're probably still vulnerable.

On my machine the Blizzard launcher only checks for updates and updates itself when you run it so if you have it installed but haven't run it in a while you might not have the most recent.

Re: Blizzard games were vulnerable to DNS rebinding attack

#18
post #2

Disappointing (lack of) response/fix Would have assumed they'd do better given how polished their consumer products are

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

The most likely candidate is that the local server would need to require authentication with credentials that a browser would be unlikely to have. Maybe write a key file to the local filesystem since both the game and the update daemon would have access, but browsers wouldn't without explicitly asking the user.

DNS rebinding vulnerabilities are an authentication/trust problem. Authors assume that 127.0.0.1 (or other private IP blocks) are safe and therefore no additional authentication is required, or that they can rely on the same origin policy to do certain things and, e.g., reject requests with the Origin header set, or as in this case, rely on the same origin policy to restrict updates to the `Authorization` header without a preflight OPTIONS request.

If you want to watch an interesting DefCon talk about the same idea, but attacking routers, this [1] is one the most entertaining/interesting talks I've seen overall.

[1] https://www.youtube.com/watch?v=FV7SQd-3Ytk

Re: Blizzard games were vulnerable to DNS rebinding attack

#19
post #6
post #3

the DNS rebinding vulnerability exists in applications other than Blizzard games, such as this one in Bittorrent Transmission also reported by Tavis Ormandy.... https://github.com/transmission/transmission/pull/468 Seems to be a quite prevalent issue...

That's because for decades binding to localhost has been taken to mean "only users on the local machine can access this". Now chrome is breaking that assumption through a leaky sandbox, and demanding everyone else change rather than fixing their own security issues.

That's false. Any website was able to send requests to 127.0.0.1 since that new thing called always. DNS rebinding has been a known vector for 10+ years.

Re: Blizzard games were vulnerable to DNS rebinding attack

#20
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?

Better library support - the state of HTTP client and server libraries is a lot better than the state of other random RPC libraries, and developers tend to be more familiar with it these days too, so it's likely to get you a better product. And very few HTTP libraries support HTTP over named pipes or UNIX sockets.
Post reply on HN