On 23/11/2022 02:56, zhangjiangyu via Dnsmasq-discuss wrote:
Hi,
On 23/11/2022 07:21, Simon via Dnsmasq-discuss wrote:
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.
Ok, Now I understand that the fairly unique architecture of dnsmasq cannot
verify all malformed packets. But I think there should be a basic detection of
the packets. sure, dnsmasq does not need to judge the legality of each record
resource data.
|like this basic record structure:
| 1 1 1 1 1 1
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | |
| / /
| / NAME /
| | |
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | TYPE |
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | CLASS |
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | TTL |
| | |
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | RDLENGTH |
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
| / RDATA /
| / /
| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The structure of the record is stationary, and the rfc stipulates that the
value of the class has a certain scope and meaning, so the clear regulation of
the dns rfc should be checked and necessary. But for the first bug, there is
really no check, I think this should be fixed.
|The following CLASS mnemonics and values are defined:
|
|IN 1 the Internet
|
|CS 2 the CSNET class (Obsolete - used only for examples in
| some obsolete RFCs)
|
|CH 3 the CHAOS class
|
|HS 4 Hesiod [Dyer 87]
Thank you very much for your reply.
This is a perfect example of why dnsmasq should not reject packets it
can't understand. If the IETF should define a new class tomorrow, every
release of dnsmasq since 2000 would be quite happy to forward queries in
that class and return results. The same goes for classes between 65280
and 65534 which are reserved for private use in RFC 6895.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2
This is all set out explicitly in section 3 of RFC 5625
https://datatracker.ietf.org/doc/html/rfc5625#page-3
Quote:
The role of the proxy should therefore be no more and no less than to
receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the whole response is returned verbatim to the
original client.
Cheers,
Simon.
Thanks,
P1n9
Cheers,
Simon.
_______________________________________________
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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
