[Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received
Petr Menšík
pemensik at redhat.com
Tue Nov 22 20:42:28 UTC 2022
Created ldns-testns files for all queries. Also contains their body
responses parsed by dig tool on that.
Interesting cases, but I am not sure how much should dnsmasq validate
those responses. Most of these responses is valid DNS responses. Sure,
not what client expected or needed, but I doubt we can make reasonable
filter on dnsmasq side.
On 19. 11. 22 0:12, Geert Stappers via Dnsmasq-discuss wrote:
> 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
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-ldns-testns-files-for-testing.patch
Type: text/x-patch
Size: 6898 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20221122/e4731f6d/attachment.bin>
More information about the Dnsmasq-discuss
mailing list