Disappointing (lack of) response/fix
Would have assumed they'd do better given how polished their consumer products are
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...
A mischievous person renting a domainname can list any public or private IP addresses in her A records; and she can list any nameservers, including ones with which she has no relationship. She can list an IP address that the user may be utilising or renting.
I use a fast DNS resolution solution that only queries authoritative servers and stores IPs in constant, perfect hash databases, then in kdb+. No caches. I see the IP addresses that are returned in DNS packets not as ephemeral and inconseqential, but as entries in a database that need to be validated before insert.
If I see some nonsense like 127.0.0.1 in an A record, let alone a public IP address that Im using, it is rejected. I have seen NS records with 127.0.0.1 as well.
Are there DNS rebinding attacks that do not use iframes, Javascript or some other way to trigger automatic lookups without user interaction? In theory perhaps. But every attack I have seen relies on triggering lookups automatically.
Its too bad the popular browsers make automatic requests for resources, automatically follow redirects and do not allow users to disable this default behavior.
However users can make use of less complex HTTP clients that do not make such automatic requests and where redirects can be disabled. These can be used in tandem with the popular browsers to give users more transparency and control.
Also isnt it possible to use SSL/TLS for localhost JSON-RPC? Theoretically couldnt users make use of client certificates?
Just a thought.
Developer 101: if you want to do a blacklist, do a whitelist instead.
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?
Would having TLS on the localhost endpoint (without client certificates) make the attack more difficult? the browser would have to validate the localhost-returned cert against the attacker.com hostname.
> 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 Blizzard has a bug, it seems to be the browser that has the real vulnerability here.
Edit: The replies have good explanations with more detail why this would be difficult to fix -- the host doesn't have enough context to differentiate between "intended" and "unintended" IPs without a bunch of pernicious edge cases.
I assume there's a similar patch for the Mac client, but this offers no protection for users running the Windows client via WINE.
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?