Multiple Heap Buffer Overflows In the Windows DNS Client | Hacker News Reader

Multiple Heap Buffer Overflows In the Windows DNS Client

bishopfox.com

83 pointsdijit30 comments

I’ve been working on https://github.com/bluejekyll/trust-dns for a bit over two years now. About a year ago a new contributor added Windows build support and testing with AppVeyor, which was awesome.

Originally I started this project more for server side stuff, but recently have been very focused on a full resolver which could be used as a replacement for the OS system resolver.

A question for HN, what would you like to see in this context that would make a replacement resolver on Windows something you’d use? To be clear, it’s not something you could use dropin right now, it can only be used as an internal library to Rust at-the-moment, but I’ve been planning to start working on a daemon that could act as a caching system resolver in the next little bit.

I don't know about Windows, but on Linux, I would love to have a replacement for the entirety of NSS (and PAM, and other similar parts of the system) that ran in separate daemons rather than by loading shared objects into my process which could arbitrarily corrupt my process if they were buggy (which I have encountered before before).

To achieve that compatibly with existing systems, it would probably need to be able to act as an NSS module itself in order to be compatible with existing clients, and also be able to load NSS modules (hopefully in sandboxed, lower privileged processes) so it could support existing setups transparently, though it would be great to also have a better asynchronous interface so that you don't have to spawn thread or process pools for things like hostname resolution or fetching groups from LDAP.

That's a really neat idea. I like the idea of potentially building something that could be plugged directly into Linux as a PAM module, etc. I've never written something like that, so it would be fun learning how to do it.

> it would be great to also have a better asynchronous interface so that you don't have to spawn thread or process pools for things like hostname resolution

The library is built atop of Tokio, so is already async capable.

On Linux, I'd really love a caching resolver that saves its cache persistently. I don't understand why the machine's power-on state has anything to do with the validity of the DNS cache; if the entries were good at shutdown time they ought to be good enough in a few seconds when I boot again.

That's very feasible, as I already have the persistence layer from the server component. So that could be reused easily. It's also portable, so would work on all the currently supported platforms, Linux, macOS and Windows.

I'm surprised this isn't the norm.

The important bit is kind of buried in the middle:

It is important to note that as the record is malformed, it should not traverse any sane DNS resolvers. Because of this, the issue can only be triggered if the victim(s) are accepting DNS responses directly from the attacker-controlled server. Typically, this would require an active Man-in-the-Middle attack.

True, though "man in the middle" can be as simple as serving up free WiFi anywhere people have laptops.

And you could name it something common without a password, like XFinity, and a ton of laptops would connect.

Or you could set up a captive portal, and phish for login credentials at the same time as you exploit the DNS resolver.

A way to protect yourself is to manually specify DNS servers - to your own, or a trusted public one like 4.4.2.2 or 8.8.8.8. It's buried in the network settings, but DNS servers can be specified even if you're getting your IP from DHCP.

This attack only works if you're getting DNS info from a malicious/compromised source. So if you're on a coffee shop WiFi, it creates another layer of complexity - the attacker would have to rewrite/spoof the DNS packets instead of simply serving the malformed packets directly.

Would that make a difference if you're getting MITM?

The coffee shop WiFi would have to rewrite the packets with a new payload. Not too difficult, but a different skillset and scope than the original attack.

No, unless you configure your IP address statically and use a VPN that doesn't require a DNS lookup to connect so basically, it's hard to avoid these issues on a rouge network.

Isn't that 4.4.4.4 or does Google also have a public DNS server on 4.4.2.2?

4.4.2.2 is Level3, now owned by CenturyLink.

Google Public DNS IPs are 8.8.8.8 and 8.8.4.4.

Source: https://developers.google.com/speed/public-dns/

And why you think that someone can make free WiFi hotspot and can't route that both IPs to it's own DNS server?

By default, probably 99.99% of devices will use the WiFi DNS. The attackers may not want to go through the difficulty of changing routes to handle that .01% exception. That 99.99% might be good enough for them.

A lot of WiFi hotspot gear has built-in functionality to intercept/redirect DNS traffic. Or, as they are routers already, the ability to do it with firewall rules and such.

We've talked about the risks of these kinds of MitM attacks for years. The good news is, the large players have vested interest to keep their networks secure.

>A lot of WiFi hotspot gear

sure, and they all run vulnerable Dnsmasq, win win.

Would a mitm attack be necessary since DNS is UDP? Couldn't you just forge packets from likely dns hosts that the victims might use and just constantly send responses hoping that the victim makes a request for one of the hosts you are forging responses for, and maybe one of the packets beats the real response and gets parsed? Is there a sequence number or unique request ID that gets used in UDP dns requests that is required in the response to be accepted as a response?

There is the UDP source port, which is where the reply will be sent, and a 16 bit ID number associated with each request. Randomizing both of these gives you 32 bits of entropy, which would makes spoofing attacks a lot harder. There were a lot of systems vulnerable to such attacks before source port randomization and ID randomization became common to mitigate such attacks.

https://en.wikipedia.org/wiki/DNS_spoofing

Of course, for this attack, you may only need to get the source port to match, since if it's the DNS resolver that has the bug, it may parse the whole response before noticing that the ID doesn't match. And some NATs may break source port randomizaiton, since they allocate their own source ports to keep a table of their source port to the internal IP and source port; if they do so in a more predictable manner, it may be relatively easy to spam them with packets, or you could just spam the whole 65536 bit range with bad packets.

> Is there a sequence number or unique request ID that gets used in UDP dns requests that is required in the response to be accepted as a response?

Yes, there is, but it's only 16 bits, so it can be guessed, as was shown a decade ago with the "Kaminsky vulnerability" (giving names to vulnerabilities is not a new thing). A workaround is to also randomize the source port, so the attacker has to guess both the query ID and the source port used for the request. The true fix for the "Kaminsky vulnerability" would be to use DNSSEC, since even if the attacker spoofs the DNS response, they can't spoof the DNSSEC signature.

Yes, this buffer overflow is in code added precisely to protect against an attacker forging DNS responses. Ironic, isn't it?

It's been many, many years since I earned my MCSx certs and, fortunately, I rarely touch a Windows box these days so I am very likely wrong... but it seems to me that the following scenario is possible.

A domain controller also acts as a DNS server. "Forwarders" can be configured, or the DC can "go direct" and perform (recursive) resolution on a client's behalf. A client that could be convinced (should be relatively easy?) to issue a certain DNS request (which would be sent to the DC) would cause a malicious response (assuming a malicious authoritative DNS server) to be sent to the DC. In the case where the DC is an affected (unpatched) Windows 2012 server, this would result in a compromise of the DC.

Sounds feasible, in theory. I don't know enough about this issue to say for certain, though.

How similar is this to the dnsmasq stuff earlier this month?

Behind the Masq: Yet More DNS and DHCP Vulnerabilities | https://news.ycombinator.com/item?id=15383574 (Oct 2017, 117 comments)

>The DNS caching service that handles the storage of DNS responses automatically restarts when it crashes, and it won’t notify the user of the crash.

Programmer one: "It keeps crashing!"

Programmer two: "Just remove the bit that tells the user it crashed and ship it!"

No one: “Just spam the user with error messages they won’t understand and can’t fix!”

Also no one: "let's fix it so it won't crash constantly"

Lots of engineers: “Just make it restart so it self-heals”

Reply on news.ycombinator.com