Multiple Heap Buffer Overflows In the Windows DNS Client (bishopfox.com)

83 points by dijit 343 days ago

30 comments

bluejekyll 343 days ago

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.

    lambda 343 days ago

    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.

      bluejekyll 343 days ago

      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.

    gue5t 343 days ago

    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.

      bluejekyll 342 days ago

      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.

      nerdponx 341 days ago

      I'm surprised this isn't the norm.

rando444 343 days ago

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.

    tyingq 343 days ago

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

      swsieber 343 days ago

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

        nerdponx 341 days ago

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

    benkillin 343 days ago

    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?

      lambda 343 days ago

      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.

      cesarb 343 days ago

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

    343 days ago

    stephengillie 343 days ago

    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.

      jonknee 343 days ago

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

        SadWebDeveloper 343 days ago

        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.

        stephengillie 343 days ago

        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.

      edwhitesell 342 days ago

      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.

        rasz 342 days ago

        >A lot of WiFi hotspot gear

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

      mobilio 343 days ago

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

        stephengillie 343 days ago

        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.

jlgaddis 343 days ago

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.

    343 days ago

KekDemaga 343 days ago

>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!"

    dpark 342 days ago

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

      KekDemaga 342 days ago

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

        dpark 342 days ago

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