-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DoS Vulnerabilities of SmartDNS (TuDoor Attack) #1829
Comments
Maybe I don't fully understand how this attack works. Lines 1828 to 1870 in 84f217d
line 1828 checks udp packet format. What's missing is a check of the server address. In addition, if there is a cache poisoning attack similar to GFW, I think it is a problem with the UDP DNS protocol. There may be no solution except DNSSEC, DOT, and DOH. |
Yeah. SmartDNS does check the txid and src port. Also, it will ignore malformed response packets. But if it receives an icmp error message (only validating the inner 4 tuples while not checking the txid), it will terminate and stop receiving any promising legal response. |
Is there a way to reproduce the problem? Or any suggestions for a fix? |
i think the simplest way to fix it is to ignore the ICMP error message. |
PoC is attached. Run the code, dig @smartdns i.domain (starts with i), if smartdns receives an ICMP error message, it will terminate the current resolution process.
|
I did some tests and couldn't reproduce the issue. upstream server is set to 1.1.1.4 script log
modified script
The test script you provided report some error, changing
smartdns log, no packets received
|
Overview
We found a new vulnerability in DNS resolving software, which triggers a resolver to ignore valid responses thus causing DoS (denial of service) for normal resolution. The effects of an exploit would be widespread and highly impactful, as the attacker could just forge a response targeting the source port of vulnerable resolver without the need to guess the correct TXID.
Vulnerability Details
After analyzing the source code of all DNS software, we locate a response preprocessing part that receives incoming packets and parses them before processing valid DNS data.
We find that there is a huge implementation difference between different DNS software on the preprocessing operation. Specially, some software just accept the first-incoming packet and ignore all the other responses for each outgoing query. Unfortunately, they don't check the packet format and TXID. If the source port is matched, these software will accept these packets.
Regarding this sort of processing, we propose a DoS attack to cause vulnerable resolvers to ignore any valid response and terminate current resolution process. We name it TuDoor attack.
General attack steps:
Malformed packets :
There are two type of malformed packets: ICMP packet and bad-format UDP packet. For example:
ICMP packet (the attacker even needn't to impersonate the remote server's IP).
Bad-format UDP packet with null or malformed DNS layer payload (the attacker needs to forge the remote server's IP).
Note:
Threat Surface
Mitigation
Resolvers should wait for a timeout until receiving a legal DNS response and ignore any malformed packets.
We recommend that all implementations should take a similar way to guarantee receiving a valid response rather than just receiving one, processing one, and ignoring others.
Reference
https://www.computer.org/csdl/proceedings-article/sp/2024/313000a181/1V28Z5fBEVG
The text was updated successfully, but these errors were encountered: