> Hi, > > On 24/11/2022 06:22, Simon via Dnsmasq-discuss wrote: > > 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. > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > After I read rfc5625, I understand what you mean. you are right. > |Section 4.3 writes: > | > |Similarly, all responses MUST be proxied regardless of the values of > | the TYPE and CLASS fields of any Resource Record therein. > > In fact, there are corresponding security considerations in rfc5625, and the > requirements for packet filtering are proposed. These points are consistent > with my previous description of dnsmasq returning SERVFAIL. The explicitly > cited example, "incorrect counts for the Question, Answer, Authority, and > Additional Sections", has the same cause as our finding > "request3-response3-combination"(Thanks to Geert Stappers for the > correction). The expected behavior for this test case should return rcode as > SERVFAIL. > > |Section 4.3 writes: > | > |Examples of malformed packets that MAY be dropped include: > | > | o invalid compression pointers (i.e., those that point outside of > | the current packet or that might cause a parsing loop) > | > | o incorrect counts for the Question, Answer, Authority, and > | Additional Sections (although care should be taken where > | truncation is a possibility) > | > |In these circumstances, proxies SHOULD synthesise a suitable DNS > |error response to the client (i.e., SERVFAIL) instead of dropping the > |packet completely. This will allow the client to detect the error > |immediately. > > Here is another bug for the same reason: > https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg16552.html > > Thank you very much for your reply. > > Thanks, > P1n9
I'm so sorry that I need to make a correction. https://datatracker.ietf.org/doc/html/rfc5625#section-6.3 |Section 6.3 writes: | |Examples of malformed packets that MAY be dropped include: | | o invalid compression pointers (i.e., those that point outside of | the current packet or that might cause a parsing loop) | | o incorrect counts for the Question, Answer, Authority, and | Additional Sections (although care should be taken where | truncation is a possibility) | |In these circumstances, proxies SHOULD synthesise a suitable DNS |error response to the client (i.e., SERVFAIL) instead of dropping the |packet completely. This will allow the client to detect the error |immediately. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
