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

[Geert Stappers]

On Sat, Nov 26, 2022 at 10:26:46PM +0000, Simon Kelley wrote:
> On 24/11/2022 02:40, zhangjiangyu via Dnsmasq-discuss wrote:
> > On 24/11/2022, zhangjiangyu via Dnsmasq-discuss wrote:
> > > 
> > > 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.
> 
> 
> I've just pushed
> 
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e939b45c9facb1b2dad688de1ce14457247615e9
> 
> which turns a malformed reply detected by the existing code parsing data for
> the DNS cache into a SERVFAIL.


--- a/CHANGELOG
+++ b/CHANGELOG
@@ -60,7 +60,9 @@ version 2.88
        Thanks to Ye Zhou for spotting the problem and an initial patch.

        If we detect that a DNS reply from upstream is malformed don't
-       return it to the requestor; send a SEVFAIL rcode instead.
+       return it to the requestor; send a SERVFAIL rcode instead.
+       Described at https://datatracker.ietf.org/doc/html/rfc5625#section-6.3
+       Thanks to Zhang Jiangyu for raising awareness of it.


 version 2.87

> 
> That should cover both the examples above.
> 

I haven't yet played with it.


Groeten
Geert Stappers
-- 
Silence is hard to parse