[Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received

Simon Kelley simon at thekelleys.org.uk
Mon Nov 21 23:00:26 UTC 2022


This behaviour arises from the way dnsmasq works. It doesn't attempt to 
completely parse the reply packet, it just sends it bit-for-bit to the 
original requestor. This has the advantage dnsmasq as a DNS forwarder is 
transparent: new packet formats or data types that it doesn't understand 
are still returned to the original requestor.

As far as security is concerned, I think it's a fundamental mistake to 
rely on dnsmasq or any upstream DNS infrastructure to protect the 
resolver code in the original requestor. DNS happens most often over 
UDP, and if the resolver is vulnerable to malformed packets it's quite 
easy to get those malformed packet to the resolver without the use of 
dnsmasq.

If you'd found a malformed packet which causes dnsmasq to misbehave, I'd 
be very interested, I'd be especially interested in any malformed 
packets that can get ad flag set when DNSSEC validation is enabled. \As 
I understand, you've found neither of those.

Forwarding untrusted DNS packets to a client which is (or should be) 
expecting untrusted DNS packets is simply not a bug, in my opinion.

Of course dnsmasq does attempt to understand the contents of replies in 
order to extract the records which it caches, and it handles any 
malformed packets it detects as part of that process. It does that by 
abandoning the caching of the records, but still returns the broken 
answer. It would be fairly simple to modify extract_addresses() to 
produce a different return value when it terminates due to a known 
malformed packet, and then turn that return code into a SERVFAIL reply. 
There would be no guarantee that the packet didn't have some of the 
malformations you list, but it would catch some nonsense packets.


Cheers,

Simon.






On 12/11/2022 02:30, ZhangJiangyu 张江瑜 via Dnsmasq-discuss wrote:
> Hi,
> 
> *Description*
> 
> When the DNS forwarder iteratively queries the malicious domain name 
> server, it returns some malformed dns packets, and dnsmasq returns the 
> packet to the client without proper verification, which will give the 
> user a distrust or malicious data.  Other authoritative dns servers have 
> done correct verification.  there are three bugs below, you can start a 
> fake domain name server locally and return specific data.
> 
> *Steps to reproduce*
> 
> 1、Turn on a fake name server and return a specific payload.
> 2、start dnsmasq. The configuration options are as follows:
> ```python
> 
> port=53
> no-daemon
> no-resolv
> server = 127.0.0.1
> bind-interfaces
> no-hosts
> 
> ```
> 
> 3、Send the corresponding dns request.
> 
> 
> *First bug*
> 
> 
> When the query class type is 0x01, the returned answer type is the wrong 
> class name in the answer, which can be forwarded to the client. The 
> wrong class type includes 0xdf01, 0x2001, 0x4001, 0x0801, 0x1001, 
> 0x0401, 0x0201, 0x0101, 0x0081, 0x0041, 0x0021, 0x0011, 0x0009, 0x0005, 
> 0x0003, 0x0000etc. The rcode of the dnsmasq returned packet is 0.
> 
> Expected/Actual behavior:
> 
> bind,maradns,knot-resolver,pdns all return the response packets with 
> rcode 2.
> 
> Reproduce data:
> The first four bytes are the length.
> request1 <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request1>
> response1 
> <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response1>
> 
> *Second bug*
> 
> When there is an error in the domain name of the answer record, dnsmasq 
> returns bad packets to the client. The rcode of the dnsmasq returned 
> packet is 0.
> 
> Expected/Actual behavior:
> 
> bind,maradns,  pdns all return the response packets with rcode 2. 
> knot-resolver return the response packets with rcode 3.
> 
> Reproduce data:
> The first four bytes are the length.
> request2 <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request2>
> response2 
> <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response2>
> 
> *Third bug*
> 
> When the DNS packet returned by the domain name server has redundant 
> data, it is not detected. The rcode of the dnsmasq returned packet is 0.
> 
> Expected/Actual behavior:
> 
> bind,maradns,  pdns all return the response packets with rcode 2. 
> knot-resolver return the response packets with rcode 3.
> 
> Reproduce data:
> The first four bytes are the length.
> request3 <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request3>
> 
> response3 
> <https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response3>
> 
> 
> Thanks
> 
> P1n9
> 
> Zhejiang University
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss



More information about the Dnsmasq-discuss mailing list