Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blizzard games were vulnerable to DNS rebinding attack

bugs.chromium.org

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Blizzard games were vulnerable to DNS rebinding attack

#51

Post by kodablah »

geofft wrote: post #41
kodablah wrote: post #32

Earlier quoted context omitted.

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)

I could believe that caching "is it localhost / RFC 1918 space or not" for a tab would have a sufficiently low false-positive and false-negative rate to be worth doing. It would still break the average business user who has an email half-written in OWA via an RFC-1918 address, puts their laptop to sleep, and goes home and expects OWA to still work over the public internet, but maybe OWA can figure out a solution ther…

I don't mind breaking legitimate uses rebinding here. I'm not familiar w/ how OWA changes IPs from private-network to public-network, but I'd say using DNS is the wrong approach. And Chrome can probably detect DNS server change and then evict its known cache anyways. Yeah, a first step is probably just localhost/private-IP specific.

Re: Blizzard games were vulnerable to DNS rebinding attack

#52

Post by syntheticnature »

iteriteratedone wrote: post #34
Jyaif wrote: post #11

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

Ok i need a whitelist of every url but ones that start with facebook ... go

...did you intend to allow fbcdn.net (a Facebook-controlled domain)?

Re: Blizzard games were vulnerable to DNS rebinding attack

#53

Post by geofft »

kodablah wrote: post #51
geofft wrote: post #41

Earlier quoted context omitted.

I could believe that caching "is it localhost / RFC 1918 space or not" for a tab would have a sufficiently low false-positive and false-negative rate to be worth doing. It would still break the average business user who has an email half-written in OWA via an RFC-1918 address, puts their laptop to sleep, and goes home and expects OWA to still work over the public internet, but maybe OWA can figure out a solution ther…

I don't mind breaking legitimate uses rebinding here. I'm not familiar w/ how OWA changes IPs from private-network to public-network, but I'd say using DNS is the wrong approach. And Chrome can probably detect DNS server change and then evict its known cache anyways. Yeah, a first step is probably just localhost/private-IP specific.

It's just that OWA is a web app that is often configured to be accessible on the internal network via an internal IP, and on the external network via an external IP (so you can get webmail even if you're not in the office), but it's the same app.

I certainly don't think it's worth supporting this from first principles - i.e., had the web been designed the way you suggest from day one, that would have been great - but it's got a very large deployment, and "Chrome silently loses your Outlook emails because of a security issue in video games and a BitTorrent client" is a good way to get Chrome removed from enterprises, and other browsers to decide not to ship the same fix....

Re: Blizzard games were vulnerable to DNS rebinding attack

#55

Post by Nadya »

jdoliner wrote: post #43
hug wrote: post #40

Earlier quoted context omitted.

In case you think this is hard: ^(?!facebook).*

This is a blacklist though.

Functionally - yes. By definition - no.

A blacklist won't allow items that match and a whitelist only allows items that match. Blacklists include by default and whitelists exclude by default.

Since the regex needs to match to be included - it is, by definition, a whitelist. It excludes by default anything that doesn't match. It just so happens the net being cast is so wide as to be "all except ____" where a whitelist is usually seen as "none except ____".

Re: Blizzard games were vulnerable to DNS rebinding attack

#56

Post by blattimwind »

geofft wrote: post #33
0x0 wrote: post #25

Earlier quoted context omitted.

It could also be an attempt at actually integrating with a regular web browser on regular web pages. Perhaps for things like launching a locally installed game to join a multiplayer match by clicking a start button on a match-making website, by triggering the local http server with a cors request? I know that at least spotify has something similar for interfacing with your locally installed desktop client on a regula…

If you want to do that, just do a normal cryptographic signature thing - have the website sign requests with a private key that's kept by Blizzard, and have clients check that requests are signed. (It sounds like that's not what's happening here because the patch checks for browser EXE names and refuses connections from them, but I'm not quite sure.)

No, the much better way to do this is with a custom URI protocol handler, e.g. steam://launch/220, which has no direct interaction between privilege domains (steam and the website).

Re: Blizzard games were vulnerable to DNS rebinding attack

#57

Post by iteriteratedone »

hug wrote: post #50
iteriteratedone wrote: post #46

Earlier quoted context omitted.

Is that not a black list? ... you are not affirming equality ... you are affirming inequality

How do you define a whitelist? A list of items, that, if matched, are allowed? That regex will only positively "match" non-facebook items, and will only block facebook if implemented in a whitelist. I'm just playing the straight man to your joke. Of course it's functionally a blacklist: That's what you asked for.

Sorry cant drop this one yet

My comment is not a joke but a challenge to the parent ... that they are wrong

Yes whitelist are safer ... but whitelists can be cumbersome to generate/maintain and slow you down at runtime ...

On reddit let this slide , but here we have to correct the flawed thinking.

You cant run from engineering problems without consequece

So now we have graduated to course 202: how to make a blacklist safe?

Check context, and restrict access

Re: Blizzard games were vulnerable to DNS rebinding attack

#58

Post by dooglius »

geofft wrote: post #29
dooglius wrote: post #21

> Any website can simply create a dns name that they are authorized to communicate with, and then make it resolve to localhost. So if I understand this correctly, websites can now bypass all firewalls and send traffic to any _local_ port at will? It also seems that this same trick would apply to local/intranet IPs (e.g. have domains that redirect to 192.168.0.x) allowing interaction with things like printers. While B…

Yes. They can't send arbitrary traffic, though; they can only send valid HTTP requests, and they don't get access to your cookies (because the hostname doesn't match), so the "only" thing they can do is get access to things that an unauthenticated HTTP client running as you could get access to. This has been true since almost the first web browsers - XHR wasn't a thing, but you could send GET requests with " rel="nof…

This makes sense, thanks for the explanation. The unfortunate thing is that setting up a local HTTP server is easy, while proper authentication takes more work. Based on the nature of their fix, it seems Blizzard doesn't really want to expend effort on proper authentication. I wonder if browsers could send a special HTTP header indicating the host that initiated the request?

Re: Blizzard games were vulnerable to DNS rebinding attack

#59

Post by Nadya »

iteriteratedone wrote: post #57
hug wrote: post #50

Earlier quoted context omitted.

How do you define a whitelist? A list of items, that, if matched, are allowed? That regex will only positively "match" non-facebook items, and will only block facebook if implemented in a whitelist. I'm just playing the straight man to your joke. Of course it's functionally a blacklist: That's what you asked for.

Sorry cant drop this one yet My comment is not a joke but a challenge to the parent ... that they are wrong Yes whitelist are safer ... but whitelists can be cumbersome to generate/maintain and slow you down at runtime ... On reddit let this slide , but here we have to correct the flawed thinking. You cant run from engineering problems without consequece So now we have graduated to course 202: how to make a blacklist…

>Check context, and restrict access

But then why do you need the blacklist?

I refer to this post by vec: https://news.ycombinator.com/item?id=16208419

If you think you need a blacklist you should probably be using a whitelist. If your problem can't be solved with a whitelist then it's probably better solved in a way that doesn't involve a blacklist or a whitelist.

Re: Blizzard games were vulnerable to DNS rebinding attack

#60

Post by kentonv »

ghostbrainalpha wrote: post #4
zajd wrote: 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?

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 it -- but it does not actually check what origin requests are addressed to. A random web site running in a browser normally cannot make requests to a hostname other than its own. Or, more precisely, it can make requests, but it can't read the responses. The Blizzard updater therefore forces the client to make an initial request whose response contains a secret token, and then subsequent requests contain that token, proving that the client was able to read the response and is therefore not a web site running in a browser.

However, it's perfectly possible to define an evil hostname whose DNS records assign it the IP address 127.0.0.1. Thus requests to this evil hostname would end up reaching the local Blizzard updater service. Unfortunately, the service will happily respond to these requests because it does not pay attention to what hostname the client was requesting.

(To actually exploit this, it's necessary to load an evil web site from the evil host name, which then performs the attack. This means that the evil hostname can't only map to 127.0.0.1, but must also map to the attack server. But a hostname can indeed have multiple DNS records, and the browser will arbitrarily switch between them, allowing an attack to proceed.)

Post reply on HN