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.
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.
> 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.
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.
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.
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?
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.
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.
sure, and they all run vulnerable Dnsmasq, win win.
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.
Behind the Masq: Yet More DNS and DHCP Vulnerabilities | https://news.ycombinator.com/item?id=15383574 (Oct 2017, 117 comments)
Programmer one: "It keeps crashing!"
Programmer two: "Just remove the bit that tells the user it crashed and ship it!"