[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