Blizzard games were vulnerable to DNS rebinding attack
11–20 of 94 posts
Re: Blizzard games were vulnerable to DNS rebinding attack
#12The 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?
Re: Blizzard games were vulnerable to DNS rebinding attack
#13Disappointing (lack of) response/fix Would have assumed they'd do better given how polished their consumer products are
Re: Blizzard games were vulnerable to DNS rebinding attack
#14the 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.
Re: Blizzard games were vulnerable to DNS rebinding attack
#15Earlier 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…
Re: Blizzard games were vulnerable to DNS rebinding attack
#16Disappointing (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 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
#17The 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
#18Disappointing (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?
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.
Re: Blizzard games were vulnerable to DNS rebinding attack
#19the 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.
Re: Blizzard games were vulnerable to DNS rebinding attack
#20So 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?