On 22/11/2022 06:47, zhangjiangyu via Dnsmasq-discuss wrote:
Hi,
On 22/11/2022 07:00:26; Simon Kelley via Dnsmasq-discuss wrote:
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.
Yes, I admit that the original requestor will have some checks, but if dnsmasq
relies on the checks of the client and the upstream DNS server, is it
inappropriate? Should dnsmasq also check accordingly? In my opinion, dnsmasq
should not return to the client a packet that does not conform to the rfc
definition, such as the first bug. I also know that DNS is mostly UDP protocol,
but it seems that the same problem exists under TCP protocol.
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.
I don't quite understand why clients expect untrusted packets.
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.
Yes, I think it is necessary to return rcode as SERVFAIL when encountering
malformed packets. Bind, maradns, pdns and knot all return packets with rcode
SERVFAIL. This behavior is compliant with the DNS RFC specification. If dnsmasq
returns the message whose rcode is SERVFAIL to the client, the client can mark
the packets as untrusted and request again without parsing all records of the
packets. I think this is also why the RFC defines the rcode field.
Thank you very much for your reply.
The main argument for this seems to be a security one: the client may
not handle a malformed packet, and a suitably crafted malformed packet
may compromise the client with a buffer overflow or similar. If the
client is sending all requests via dnsmasq, then dnsmasq should detect
and eliminate malformed packets from upstream rather than sending them
to the client as this protects the client from compromise.
If we have a client which is vulnerable to malformed packets then the
solution is to fix the client, not put it behind dnsmasq. Putting the
client behind dnsmasq and relying on dnsmasq to intercept malformed
packets is not fix since and attacker may be able to send malformed
packets direct to the client anyway or the configuration may change such
that the client talks directly to other servers which the attacker may
have control over. Using dnsmasq to filter malformed packets from the
client is at best fragile and at worst doesn't work. It also transfers
the responsibility to handle untrusted data from the client to dnsmasq,
which is the wrong approach.
Dnsmasq has to accept malformed packets from the internet without
crashing or being compromised, and, as far as anyone knows, it does.
Because of the fairly unique architecture of dnsmasq, altering it to
only return known correctly formed packets is a large change which adds
to the code footprint, increases that chance that something which is in
fact correct but encodes DNS data which dnsmasq doesn't understand will
be rejected by mistake, and can't guarantee to catch all malformed
packets anyway.
I can see the argument for flagging packets which dnsmasq detects are
malformed as part of it's code to extract data for caching, but I don't
think attempting to detect all malformed packets is required. the only
reason to do that is to protect vulnerable clients, and that problem is
fixed by fixing the clients.
Cheers,
Simon.
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Thanks,
P1n9
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
