[Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received
Geert Stappers
stappers at stappers.nl
Fri Nov 18 23:12:50 UTC 2022
On Wed, Nov 16, 2022 at 11:15:08AM +0800, zhangjiangyu via Dnsmasq-discuss wrote:
> Hi，
>
> On Mon, Nov 15, 2022 at 8:15:00PM +0800, Petr Menšík wrote:
> > Interesting tests.
> >
> > But dnsmasq is somehow naive in parsing replied queries. It tries to
> > deliver the response exactly as it were delivered to it. I think the
> > main reason for it is it expects trusted resolvers to be used as a
> > forwarding servers, not something bogus. Sure, I admit that might not be
> > correct expectation. dnsmasq is minimalistic and tries to minimize the
> > size of code and used resources. Therefore it does not do full parsing
> > of the message and verification of every aspect in the response.
> >
> > I would recommend using Unbound for less trusted forwarders. I think all
> > other implementations do not rely on recursive server doing the hard
> > work, so they may encounter also less trusted responses. But dnsmasq
> > should send queries to trusted forwarders only. It can therefore trust
> > them to do more strict checking.
>
> Unfortunately the unbound also has the same problem, I also submitted
> an issue. Although the forwarders configured by dnsmasq are trusted,
> there are also some situations that need to be considered, such as,
> the dnsmasq configuration file has been maliciously changed, your
> trusted forwarder has the same error handling problem or the host
> computer where the forwarder is located is attacked, so dnsmasq needs
> to do some obvious wrong checks, and it is also necessary.it can't
> rely entirely on other parsers.
>
> >
> > But I admit we should add at least the most obvious checks. Would you
> > please make the responses in ldns-testns [1] server format, so it would
> > be easier to test it? It allows also encoding the body in hex format, so
> > invalid responses are broken as well. It would be easier to test the bad
> > behaviour and prepare fixes for them. Are those links leading to DNS in
> > wire format? It would be simpler to read if pcap with them were used,
> > wireshark would visualise those responses well.
>
> Yes, The message I provided is a wire format,
> but it is a bit different from the wire format,
> because the first four bytes are a length field.
Ah, a length field, a sixtyfour bit length field.
> I removed the length field,
> it should be all dns request and reply messages, it is wire format.
;-)
> Below is the download link:
> origin request: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request0
> origin response: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response0
> request1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request1
> response1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response1
> request2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request2
> response2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response2
> request3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request3
> response3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response3
>
> Of course, in previous comminicate, Geert Stappers
> has already made a reproduced git repository,
> here: https://git.sr.ht/~stappers/cert_check_by_dnsmasq, you can use
> this to reproduce it.
>
> For ldns-testns, I don't know how to construct the corresponding data format,
A working example, also attached (and in the above named git repository)
-----8<----8<------8<------------
; ldns-testns data file
;
; Intented use
; ldns-testns -p 53531 this_file_name
; or
; ldns-testns -v -p 53531 this_file_name
; In other session, query with
; dig @localhost -p 53531 -t A cert00.example
; dig @localhost -p 53531 -t CERT cert00.example
; or tell dnsmasq to use this test name server by
; server=127.0.0.1#53531
;
;
$TTL 3600
ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY QUERY
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN CERT
HEX_ANSWER_BEGIN
e1 0c 81 80 00 01 00 01 00 02 00 01
06 63 65 72 74 30 30 07 65 78 61 6d 70 6c 65
00 00
25 00 01
c0 0c 00 25 00 01 00 00 00 00 00 55 ff fe ff ff
fe 33 11 5c 6f 2f 64 ff 2b de 74 c7 d0 80 ac e1
1f 97 ab d0 cb bf bc 82 f3 e3 92 24 b2 47 1e 14
68 22 58 29 ff 1b 11 e1 6a 2e 95 02 e1 c0 a0 d5
33 e1 8a 14 d6 d5 5f 48 24 aa 41 89 fa ff fd 75
53 a3 65 77 cd 23 11 e0 bc 69 3a ce f8 a2 a6 09
a6 c0 13 00 02 00 01 00 00 00 00 00 06 03 6e 73
34 c0 13 c0 13 00 02 00 01 00 00 00 00 00 06 03
6e 73 32 c0 13 00 00 29 10 00 00 00 00 00 00 00
HEX_ANSWER_END
ENTRY_END
ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN A
HEX_ANSWER_BEGIN
a5 d5 85 80 00 01 00 01 00 00 00 01
06 63 65 72 74 30 30 ; cert00
07 65 78 61 6d 70 6c 65 ; example
00 00 01 00 01 c0 0c 00 01 00 01 00 01 51 80 00 04
c0 00 02 60 ; 192.0.2.96
00 00 29 04 d0 00 00 00 00 00 1c 00
0a 00 18 fc 1c f8 16 de 56 60 db 01 00 00 00 63
71 51 9c a7 41 c7 90 7b 7a 87 c4
HEX_ANSWER_END
ENTRY_END
;
; Visit https://www.nlnetlabs.nl/documentation/ldns/index.html
; for more information about 'ldns'. It is the project that provides
; the `ldns-testns` executable.
;
; l l
-----8<----8<------8<------------
> so I can only provide complete dns request and response messages.
;-)
> But I think the structure of these packets is relatively simple,
> and it is very easy to analyze where the problem is.
>
> >
> > But as I said already, unlike other mentioned implementations, dnsmasq
> > will accept responses ONLY from configured addresses. It will never use
> > any other for iterative queries from root. Because it does not know how
> > to do that. So if the forwarder ensures those packets have valid format,
> > dnsmasq just relies on it. It is not possible to send query for
> > attacker's name and get around the forwarder's checking. I think at
> > least the 1st bug should be fixed, others can rely on forwarder's checks.
> >
>
> I think the second bug is also an obvious one, since the domain name
> of the query is not the same as the answer, it deserves to be fixed.
>
> Thank you very much for your reply.
>
> Regards,
> P1n9
Groeten
Geert Stappers
--
Silence is hard to parse
-------------- next part --------------
; ldns-testns data file
;
; Intented use
; ldns-testns -p 53531 this_file_name
; or
; ldns-testns -v -p 53531 this_file_name
; In other session, query with
; dig @localhost -p 53531 -t A cert00.example
; dig @localhost -p 53531 -t CERT cert00.example
; or tell dnsmasq to use this test name server by
; server=127.0.0.1#53531
;
;
$TTL 3600
ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY QUERY
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN CERT
HEX_ANSWER_BEGIN
e1 0c 81 80 00 01 00 01 00 02 00 01
06 63 65 72 74 30 30 07 65 78 61 6d 70 6c 65
00 00
25 00 01
c0 0c 00 25 00 01 00 00 00 00 00 55 ff fe ff ff
fe 33 11 5c 6f 2f 64 ff 2b de 74 c7 d0 80 ac e1
1f 97 ab d0 cb bf bc 82 f3 e3 92 24 b2 47 1e 14
68 22 58 29 ff 1b 11 e1 6a 2e 95 02 e1 c0 a0 d5
33 e1 8a 14 d6 d5 5f 48 24 aa 41 89 fa ff fd 75
53 a3 65 77 cd 23 11 e0 bc 69 3a ce f8 a2 a6 09
a6 c0 13 00 02 00 01 00 00 00 00 00 06 03 6e 73
34 c0 13 c0 13 00 02 00 01 00 00 00 00 00 06 03
6e 73 32 c0 13 00 00 29 10 00 00 00 00 00 00 00
HEX_ANSWER_END
ENTRY_END
ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN A
HEX_ANSWER_BEGIN
a5 d5 85 80 00 01 00 01 00 00 00 01
06 63 65 72 74 30 30 ; cert00
07 65 78 61 6d 70 6c 65 ; example
00 00 01 00 01 c0 0c 00 01 00 01 00 01 51 80 00 04
c0 00 02 60 ; 192.0.2.96
00 00 29 04 d0 00 00 00 00 00 1c 00
0a 00 18 fc 1c f8 16 de 56 60 db 01 00 00 00 63
71 51 9c a7 41 c7 90 7b 7a 87 c4
HEX_ANSWER_END
ENTRY_END
;
; Visit https://www.nlnetlabs.nl/documentation/ldns/index.html
; for more information about 'ldns'. It is the project that provides
; the `ldns-testns` executable.
;
; l l
More information about the Dnsmasq-discuss
mailing list