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

[Geert Stappers via Dnsmasq-discuss]

On Sat, Nov 19, 2022 at 12:12:50AM +0100, Geert Stappers via Dnsmasq-discuss 
wrote:
> On Wed, Nov 16, 2022 at 11:15:08AM +0800, zhangjiangyu via Dnsmasq-discuss 
> wrote:
> > On Mon, Nov 15, 2022 at 8:15:00PM +0800, Petr Menšík wrote:
> > > 
> > > But I admit we should add at least the most obvious checks. Would you 
> > > please make the responses in ldns-testns 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.
} Ah, a length field, a thirtytwo bit length field.

It took me a while to figure that it was,
because it was not needed in the Python scripts.


> > I removed the length field,

I don't know where, but I did something simular
in 
https://git.sr.ht/~stappers/cert_check_by_dnsmasq/commit/0806f6bf81d8d0aff6c18c53e0f703816520db55


Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Mon, Nov 14, 2022 at 02:36:46PM +0100, Geert Stappers via Dnsmasq-discuss 
wrote:
> On Mon, Nov 14, 2022 at 11:15:13AM +0800, zhangjiangyu via Dnsmasq-discuss 
> wrote:
> > On Sun, Nov 13, 2022 at 9:15:43PM +0800, Geert Stappers via Dnsmasq-discuss 
> > wrote:
> > > 
> > > What I think what would help for getting more attention to the "problem",
> > > is having a `request0` and `response0` that is a valid / known good
> > > CERT query. 
> > 
> > Hi,
> > 
> > The original valid response is like this:
> > |HEADER
> > |31  32  81  80  00  01  00  01  00  02  00  01
> > |
> > |QUESTION
> > |06  63  65  72  74  30  31  07  65  78  61  6d  70  6c  65  00 00  25 00  
> > 01
> > |
> > |ANSWER
> > |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
> > |
> > |AUTHORITY
> > |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
> > |
> > |ADDITIONAL
> > |00  00  29  10  00  00  00 00  00  00  00
> > Here is the download link for the valid message:
> > * request0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/request0
> > * response0 file: 
> > https://643684107.oss-cn-beijing.aliyuncs.com/dns/response0
> 
> Downloaded and added to public git repository 
> https://git.sr.ht/~stappers/cert_check_by_dnsmasq
>  ( Do `git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq` for 
> getting a clone of it. )
> 
> 
> > It can be found by comparison. 
> 
> What I noticed is that dnsmasq, version 2.87 as in Debian, did not
> return response0 when request0 was asked.

Because the length prefix.


> The request-response-combos 1, 2 and 3 did work with the same dnsmasq.

Those combos had four bytes of length information at the beginning
of the file. And the Pyton scripts expect that those four are present.

> I shall retry with most recent dnsmasq. (Next action for this is for me.)
> 
> 
> > * For the first bug, The class value of answer record returned by
> >   response1 is wrong, but it is accepted by dnsmasq and returned to
> >   the client. Any modification of the answer record's class value is
> >   acceptable. The rcode of the dnsmasq returned packet is 0.
> > * For the second bug, The domain name compression pointer of answer
> >   record returned by response1 is wrong. The query domain name does
> >   not match the answer domain name. The rcode of the dnsmasq returned
> >   packet is 0.
> > * For the third bug, When the DNS packet returned by the domain name
> >   server has redundant data, it is not detected. The rcode of the
> >   dnsmasq returned packet is 0.
> 
> That information will I add to the above mentioned git repository.
 
Done (a while ago  (I might have report it already))
 
> > For these problems, other open source dns software has done correct
> > verification and returned to the client the message with rcode 2 or 3.
> 
> Yes.  Meanwhile I do understand what is being reported. It is the
> reason why I named the git repo  "cert check by dnsmasq".
> 
>  
> > > With `host -p 5353 -t CERT cert01.example.com 127.0.0.1`
> > > or `dig @127.0.0.1 -p 5353 -t CERT cert01.example.com` being a replacement
> > > for the `python3 dns_request.py request0 5353`.
> > 
> > For this, I use the python code to receive the message forwarded to
> > the client for analysis.
> 
> Not sure if I did get that. Thing is that I now get why there
> is `dns_request.py` insteadof `dig` / `host`.  Having build a 'requestA'
> plus 'responseA', doing `dig @127.0.0.1 -t A -p 53530 cert01.example.com`
> and seeing 'bad' in
>   ; COOKIE: fc1cf816de5660db01006371519ca741c7907b7a87c4 (bad)
> got me understand it.
> 
> 
> Groeten
> Geert Stappers
> 
> 
> P.S.
> 
> After doing
> 
>git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq
>cd cert_check_by_dnsmasq
> 
> I recomment doing `git log --reverse` do read how it evolved.

Update version  (-:

git pull
git log --reverse --since 2022-11-14
  

Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Sat, Nov 26, 2022 at 10:26:46PM +, 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

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Simon Kelley]

On 24/11/2022 02:40, zhangjiangyu via Dnsmasq-discuss wrote:

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.


Chee

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

[Petr Menšík]

Should we think about an option, let's say strict-dns, which would 
toggle additional checks on incoming packets? Like ensuring the packet 
is not longer than expected. New extensions have been added to EDNS 
pseudosection, I doubt that would change anytime soon. It may filter out 
also not matching class in responses, when such class were not used in 
the question. Though that would require explicit remembering of class, 
which is not stored now. Class is used only as part of hash in question, 
so checking class in answer and additional section is not possible now.


While I agree clients should be fixed too, network DNS cache is often 
the most prominent place to add checks. We support blocking lists. We 
might allow also some additional checks. Because more and more devices 
lacks updates after few years of service. At least some checks possible 
would be great option.


I don't think dnsmasq fully qualifies as this proxy. It has even EDNS 
support and is usually caching.


I agree the resolver must accept any query and class combination and 
deliver a response for it. But I am not sure whether resolver must 
deliver response with a different class from the original query. I doubt 
that is mandatory by any RFC. I am not sure this is meant by


https://www.rfc-editor.org/rfc/rfc5625.html#section-4.3

Cheers,
Petr

On 11/23/22 23:22, Simon Kelley 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

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

[zhangjiangyu via Dnsmasq-discuss]

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

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

[zhangjiangyu via Dnsmasq-discuss]

> 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/assi

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

[Simon Kelley]

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
D

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

[Geert Stappers via Dnsmasq-discuss]

On Tue, Nov 22, 2022 at 09:42:28PM +0100, Petr Menšík wrote:
> 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:
> > > On Mon, Nov 15, 2022 at 8:15:00PM +0800, Petr Menšík wrote:
> > > > > ...
> > > > But I admit we should add at least the most obvious checks. Would you
> > > > please make the responses in ldns-testns 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.
> > > 
> > >  ...
> > > 
> > > For ldns-testns, I don't know how to construct the corresponding data 
> > > format,
> > A working example,  also attached
> > -8<8<--8<
> > ; ldns-testns data file
> > ;
 
> > 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.
> >;-)
> > 
> Created ldns-testns files for all queries. Also contains their body
> responses parsed by dig tool on that.

Thanks, they are added
to https://git.sr.ht/~stappers/cert_check_by_dnsmasq
 
However: Not yet verified.

When I have seen them working, there will be an attempt to merge to
files into a single ldns-testns-data file. So testing a next request can
be done without the need for stopping ldns-testns and restarting it with
a next response file. It will imply that requests need to differ. The
idea is changing 'cert01.example' in request2 and response2 into
'cert02.example', for request3 and response3 into 'cert03.example'. 


> 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.
 
In https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q4/016721.html
is it being discussed.


Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Wed, Nov 23, 2022 at 10:56:20AM +0800, zhangjiangyu via Dnsmasq-discuss 
wrote:
> 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.

So true


> > Dnsmasq has to accept malformed packets from the internet without 
> > crashing or being compromised, and, as far as anyone knows, it does. 

And I'm very happy with that.


> > 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.
 
I think that many many things[1] should be fixed.
Just thinking about it will not bring the desired improvements.

Please move away from "the first bug".
Use a name like "request1-response1-combination"
Describe what the outcome should be. In the begin of this email thread
there was "RC 2" and "RC 3", if I recall correct. Later on there was
SERVFAIL. I hope that SERVFAIL is either "RC 2" or "RC 3". My point is
that I'm lost in what/which solution is wished for.


> |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]


Yes, please elaborate.

Long version of the "Yes, please elaborate":
  Acknowlegde on 'There are only four CLASS mnemonics: IN, CS, CH and HS'
  Want are you expecting from the people you are addressing?


 
> Thank you very much for your reply.
> 
> Thanks,
> P1n9

Gr

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

[zhangjiangyu via Dnsmasq-discuss]

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.

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

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

[Simon Kelley]

On 22/11/2022 06:47, zhangjiangyu via Dnsmasq-discuss wrote:

Hi,

On 22/11/2022 07:00:26; Simon Kelley via Dnsmasq-discuss wrote:

This behaviour arises from the way dnsmasq works. It doesn't attempt to
completely parse the reply packet, it just sends it bit-for-bit to the
original requestor. This has the advantage dnsmasq as a DNS forwarder is
transparent: new packet formats or data types that it doesn't understand
are still returned to the original requestor.

As far as security is concerned, I think it's a fundamental mistake to
rely on dnsmasq or any upstream DNS infrastructure to protect the
resolver code in the original requestor. DNS happens most often over
UDP, and if the resolver is vulnerable to malformed packets it's quite
easy to get those malformed packet to the resolver without the use of
dnsmasq.


Yes, I admit that the original requestor will have some checks, but if dnsmasq 
relies on the checks of the client and the upstream DNS server, is it 
inappropriate? Should dnsmasq also check accordingly? In my opinion, dnsmasq 
should not return to the client a packet that does not conform to the rfc 
definition, such as the first bug. I also know that DNS is mostly UDP protocol, 
but it seems that the same problem exists under TCP protocol.



If you'd found a malformed packet which causes dnsmasq to misbehave, I'd
be very interested, I'd be especially interested in any malformed
packets that can get ad flag set when DNSSEC validation is enabled. \As
I understand, you've found neither of those.

Forwarding untrusted DNS packets to a client which is (or should be)
expecting untrusted DNS packets is simply not a bug, in my opinion.



I don't quite understand why clients expect untrusted packets.


Of course dnsmasq does attempt to understand the contents of replies in
order to extract the records which it caches, and it handles any
malformed packets it detects as part of that process. It does that by
abandoning the caching of the records, but still returns the broken
answer. It would be fairly simple to modify extract_addresses() to
produce a different return value when it terminates due to a known
malformed packet, and then turn that return code into a SERVFAIL reply.
There would be no guarantee that the packet didn't have some of the
malformations you list, but it would catch some nonsense packets.


Yes, I think it is necessary to return rcode as SERVFAIL when encountering 
malformed packets. Bind, maradns, pdns and knot all return packets with rcode 
SERVFAIL. This behavior is compliant with the DNS RFC specification. If dnsmasq 
returns the message whose rcode is SERVFAIL to the client, the client can mark 
the packets as untrusted and request again without parsing all records of the 
packets. I think this is also why the RFC defines the rcode field.

Thank you very much for your reply.



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.



Cheers,

Simon.





Cheers,

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dns

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

[Petr Menšík]

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

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

[zhangjiangyu via Dnsmasq-discuss]

Hi,

On 22/11/2022 07:00:26; Simon Kelley via Dnsmasq-discuss wrote:
> This behaviour arises from the way dnsmasq works. It doesn't attempt to 
> completely parse the reply packet, it just sends it bit-for-bit to the 
> original requestor. This has the advantage dnsmasq as a DNS forwarder is 
> transparent: new packet formats or data types that it doesn't understand 
> are still returned to the original requestor.
> 
> As far as security is concerned, I think it's a fundamental mistake to 
> rely on dnsmasq or any upstream DNS infrastructure to protect the 
> resolver code in the original requestor. DNS happens most often over 
> UDP, and if the resolver is vulnerable to malformed packets it's quite 
> easy to get those malformed packet to the resolver without the use of 
> dnsmasq.

Yes, I admit that the original requestor will have some checks, but if dnsmasq 
relies on the checks of the client and the upstream DNS server, is it 
inappropriate? Should dnsmasq also check accordingly? In my opinion, dnsmasq 
should not return to the client a packet that does not conform to the rfc 
definition, such as the first bug. I also know that DNS is mostly UDP protocol, 
but it seems that the same problem exists under TCP protocol.

> 
> If you'd found a malformed packet which causes dnsmasq to misbehave, I'd 
> be very interested, I'd be especially interested in any malformed 
> packets that can get ad flag set when DNSSEC validation is enabled. \As 
> I understand, you've found neither of those.
> 
> Forwarding untrusted DNS packets to a client which is (or should be) 
> expecting untrusted DNS packets is simply not a bug, in my opinion.
> 

I don't quite understand why clients expect untrusted packets.

> Of course dnsmasq does attempt to understand the contents of replies in 
> order to extract the records which it caches, and it handles any 
> malformed packets it detects as part of that process. It does that by 
> abandoning the caching of the records, but still returns the broken 
> answer. It would be fairly simple to modify extract_addresses() to 
> produce a different return value when it terminates due to a known 
> malformed packet, and then turn that return code into a SERVFAIL reply. 
> There would be no guarantee that the packet didn't have some of the 
> malformations you list, but it would catch some nonsense packets.

Yes, I think it is necessary to return rcode as SERVFAIL when encountering 
malformed packets. Bind, maradns, pdns and knot all return packets with rcode 
SERVFAIL. This behavior is compliant with the DNS RFC specification. If dnsmasq 
returns the message whose rcode is SERVFAIL to the client, the client can mark 
the packets as untrusted and request again without parsing all records of the 
packets. I think this is also why the RFC defines the rcode field.

Thank you very much for your reply.

> 
> 
> Cheers,
> 
> Simon.
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Thanks,
P1n9
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Simon Kelley]

This behaviour arises from the way dnsmasq works. It doesn't attempt to 
completely parse the reply packet, it just sends it bit-for-bit to the 
original requestor. This has the advantage dnsmasq as a DNS forwarder is 
transparent: new packet formats or data types that it doesn't understand 
are still returned to the original requestor.


As far as security is concerned, I think it's a fundamental mistake to 
rely on dnsmasq or any upstream DNS infrastructure to protect the 
resolver code in the original requestor. DNS happens most often over 
UDP, and if the resolver is vulnerable to malformed packets it's quite 
easy to get those malformed packet to the resolver without the use of 
dnsmasq.


If you'd found a malformed packet which causes dnsmasq to misbehave, I'd 
be very interested, I'd be especially interested in any malformed 
packets that can get ad flag set when DNSSEC validation is enabled. \As 
I understand, you've found neither of those.


Forwarding untrusted DNS packets to a client which is (or should be) 
expecting untrusted DNS packets is simply not a bug, in my opinion.


Of course dnsmasq does attempt to understand the contents of replies in 
order to extract the records which it caches, and it handles any 
malformed packets it detects as part of that process. It does that by 
abandoning the caching of the records, but still returns the broken 
answer. It would be fairly simple to modify extract_addresses() to 
produce a different return value when it terminates due to a known 
malformed packet, and then turn that return code into a SERVFAIL reply. 
There would be no guarantee that the packet didn't have some of the 
malformations you list, but it would catch some nonsense packets.



Cheers,

Simon.






On 12/11/2022 02:30, ZhangJiangyu 张江瑜 via Dnsmasq-discuss wrote:

Hi,

*Description*

When the DNS forwarder iteratively queries the malicious domain name 
server, it returns some malformed dns packets, and dnsmasq returns the 
packet to the client without proper verification, which will give the 
user a distrust or malicious data.  Other authoritative dns servers have 
done correct verification.  there are three bugs below, you can start a 
fake domain name server locally and return specific data.


*Steps to reproduce*

1、Turn on a fake name server and return a specific payload.
2、start dnsmasq. The configuration options are as follows：
```python

port=53
no-daemon
no-resolv
server = 127.0.0.1
bind-interfaces
no-hosts

```

3、Send the corresponding dns request.


*First bug*


When the query class type is 0x01, the returned answer type is the wrong 
class name in the answer, which can be forwarded to the client. The 
wrong class type includes 0xdf01, 0x2001, 0x4001, 0x0801, 0x1001, 
0x0401, 0x0201, 0x0101, 0x0081, 0x0041, 0x0021, 0x0011, 0x0009, 0x0005, 
0x0003, 0xetc. The rcode of the dnsmasq returned packet is 0.


Expected/Actual behavior:

bind，maradns，knot-resolver，pdns all return the response packets with 
rcode 2.


Reproduce data：
The first four bytes are the length.
request1 
response1 



*Second bug*

When there is an error in the domain name of the answer record, dnsmasq 
returns bad packets to the client. The rcode of the dnsmasq returned 
packet is 0.


Expected/Actual behavior:

bind，maradns,  pdns all return the response packets with rcode 2. 
knot-resolver return the response packets with rcode 3.


Reproduce data：
The first four bytes are the length.
request2 
response2 



*Third bug*

When the DNS packet returned by the domain name server has redundant 
data, it is not detected. The rcode of the dnsmasq returned packet is 0.


Expected/Actual behavior:

bind，maradns,  pdns all return the response packets with rcode 2. 
knot-resolver return the response packets with rcode 3.


Reproduce data：
The first four bytes are the length.
request3 

response3 




Thanks

P1n9

Zhejiang University


___
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

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

[Geert Stappers via Dnsmasq-discuss]

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://ww

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

[zhangjiangyu via Dnsmasq-discuss]

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. 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, 
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
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Petr Menšík]

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.


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.


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.


Regards,
Petr

[1] https://linux.die.net/man/1/ldns-testns

On 11/12/22 03:30, ZhangJiangyu 张江瑜 via Dnsmasq-discuss wrote:
The rcode of the dnsmasq returned 


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Mon, Nov 14, 2022 at 11:15:13AM +0800, zhangjiangyu via Dnsmasq-discuss 
wrote:
> On Sun, Nov 13, 2022 at 9:15:43PM +0800, Geert Stappers via Dnsmasq-discuss 
> wrote:
> > 
> > >  
> > 
> > However I don't understand the problem.
> > 
> > What I think what would help for getting more attention to the "problem",
> > is having a `request0` and `response0` that is a valid / known good
> > CERT query. 
> 
> Hi,
> 
> The original valid response is like this:
> |HEADER
> |31  32  81  80  00  01  00  01  00  02  00  01
> |
> |QUESTION
> |06  63  65  72  74  30  31  07  65  78  61  6d  70  6c  65  00 00  25 00  01
> |
> |ANSWER
> |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
> |
> |AUTHORITY
> |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
> |
> |ADDITIONAL
> |00  00  29  10  00  00  00 00  00  00  00
> Here is the download link for the valid message:
> * request0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/request0
> * response0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/response0

Downloaded and added to public git repository 
https://git.sr.ht/~stappers/cert_check_by_dnsmasq
 ( Do `git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq` for getting 
a clone of it. )


> It can be found by comparison. 

What I noticed is that dnsmasq, version 2.87 as in Debian, did not
return response0 when request0 was asked.  The request-response-combos 1,
2 and 3 did work with the same dnsmasq.
I shall retry with most recent dnsmasq. (Next action for this is for me.)


> * For the first bug, The class value of answer record returned by
>   response1 is wrong, but it is accepted by dnsmasq and returned to
>   the client. Any modification of the answer record's class value is
>   acceptable. The rcode of the dnsmasq returned packet is 0.
> * For the second bug, The domain name compression pointer of answer
>   record returned by response1 is wrong. The query domain name does
>   not match the answer domain name. The rcode of the dnsmasq returned
>   packet is 0.
> * For the third bug, When the DNS packet returned by the domain name
>   server has redundant data, it is not detected. The rcode of the
>   dnsmasq returned packet is 0.

That information will I add to the above mentioned git repository.


> For these problems, other open source dns software has done correct
> verification and returned to the client the message with rcode 2 or 3.

Yes.  Meanwhile I do understand what is being reported. It is the
reason why I named the git repo  "cert check by dnsmasq".

 
> > With `host -p 5353 -t CERT cert01.example.com 127.0.0.1`
> > or `dig @127.0.0.1 -p 5353 -t CERT cert01.example.com` being a replacement
> > for the `python3 dns_request.py request0 5353`.
> 
> For this, I use the python code to receive the message forwarded to
> the client for analysis.

Not sure if I did get that. Thing is that I now get why there
is `dns_request.py` insteadof `dig` / `host`.  Having build a 'requestA'
plus 'responseA', doing `dig @127.0.0.1 -t A -p 53530 cert01.example.com`
and seeing 'bad' in
  ; COOKIE: fc1cf816de5660db01006371519ca741c7907b7a87c4 (bad)
got me understand it.


Groeten
Geert Stappers


P.S.

After doing

   git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq
   cd cert_check_by_dnsmasq

I recomment doing `git log --reverse` do read how it evolved.
 
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[zhangjiangyu via Dnsmasq-discuss]

On Sun, Nov 13, 2022 at 9:15:43PM +0800, Geert Stappers via Dnsmasq-discuss 
wrote:
> Upon "run" I get something like:
> 
> | $ python3 dns_request.py request3 5353
> | b'12\x81\x80\x00\x01\x02\x00\x01\x06cert01\x07example...\x03ns2\xc0\x13'
> | $
> 
> 
> The how to reproduce question is answered.  Thanks.
> 
> 
> However I don't understand the problem.
> 
> What I think what would help for getting more attention to the "problem",
> is having a `request0` and `response0` that is a valid / known good
> CERT query. 

Hi,

The original valid response is like this:
|HEADER
|31  32  81  80  00  01  00  01  00  02  00  01
|
|QUESTION
|06  63  65  72  74  30  31  07  65  78  61  6d  70  6c  65  00 00  25 00  01
|
|ANSWER
|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
|
|AUTHORITY
|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
|
|ADDITIONAL
|00  00  29  10  00  00  00 00  00  00  00
Here is the download link for the valid message:
* request0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/request0
* response0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/response0

It can be found by comparison. 
* For the first bug, The class value of answer record returned by response1 is 
wrong, but it is accepted by dnsmasq and returned to the client. Any 
modification of the answer record's class value is acceptable. The rcode of the 
dnsmasq returned packet is 0.
* For the second bug, The domain name compression pointer of answer record 
returned by response1 is wrong. The query domain name does not match the answer 
domain name. The rcode of the dnsmasq returned packet is 0.
* For the third bug, When the DNS packet returned by the domain name server has 
redundant data, it is not detected. The rcode of the dnsmasq returned packet is 
0.
* For these problems, other open source dns software has done correct 
verification and returned to the client the message with rcode 2 or 3.

> With `host -p 5353 -t CERT cert01.example.com 127.0.0.1`
> or `dig @127.0.0.1 -p 5353 -t CERT cert01.example.com` being a replacement
> for the `python3 dns_request.py request0 5353`.

For this, I use the python code to receive the message forwarded to the client 
for analysis.

Thanks,
P1n9
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Sun, Nov 13, 2022 at 10:23:55AM +0800, zhangJiangyu via Dnsmasq-discuss 
wrote:
> On Sat, Nov 12, 2022 at 04:15:38PM +0800, Geert Stappers via Dnsmasq-discuss 
> wrote:
> > On Sat, Nov 12, 2022 at 10:30:09AM +0800, ZhangJiangyu 张江瑜 via 
> > Dnsmasq-discuss wrote:
> > > Hi,
> > > 
> > > Description
> > > 
> > > When the DNS forwarder iteratively queries the malicious domain name
> > > server, it returns some malformed dns packets, and dnsmasq returns the
> > > packet to the client without proper verification, which will give the
> > > user a distrust or malicious data.  Other authoritative dns servers
> > > have done correct verification.  there are three bugs below, you can
> > > start a fake domain name server locally and return specific data.
> > > 
> > > Steps to reproduce
> > > 
> > > 1、Turn on a fake name server and return a specific payload.
> 
> > How?
> 
> You need a few steps to reproduce:
> 
> * Run the command (sudo python3 dns_server.py "response filename
>   path") to listen on port 53. This will start a fake dns server,
>   receive the request, and return the result.
> * Start the dnsmasq software to listen on port 5353.
> * The configuration file is as follows:
>   "port=5353
>no-daemon
>no-resolv
>server = 127.0.0.1
 server = 127.0.0.1#53531

See below for why


>bind-interfaces
>no-hosts"
> * Run the command (./dnsmasq -C ./dnsmasq.conf) to start the dnsmasq.
> * Run the command (python3 dns_request.py "request filename path"
>   5353) to send the request, dnsmasq will forward the request to our
>   fake dns server, return the message and then return it to the client.
> * Analyze the message returned to the client, you will find that
>   there is a problem with the message, and the correct verification
>   is not done.
> 
> Next, I will give the download link of the corresponding python
> script, request file and response file, which can be reproduced after
> downloading.
> 
> * dns_server.py
> * https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_server.py

} import os
} import sys
} import socket
} import struct
} import threading
} 
} def done(sock):
} try:
} sock.shutdown(socket.SHUT_RDWR)
} sock.close()
} except Exception as e:
} pass
} 
} # The UDP server is contacted first
} def udp_server(name):
} sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
} sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
} server_address = '0.0.0.0'
} server_port = 53
  server_port = 53531  # avoid conflict with existing DNS

} 
} sock.bind((server_address, server_port))
} while True:
} try:
} recvd, client_address = sock.recvfrom(65535)
} 
} print(recvd)
} 
} inputfile = name
} data = None
} with open(inputfile, 'rb') as f:
} data = f.read()
} data = data[4:]
} data = data[2:]
} 
} print(recvd[:2] + data)
} 
} if len(recvd) > 2:
} sent = sock.sendto(recvd[:2] + data, client_address)
} except Exception as e:
} pass
} 
} done(sock)
} 
} def main():
} global stop_server
} 
} stop_server = False   
} 
} # Sets up one server on UDP port 53 
} udp_server(sys.argv[1])
} 
} os._exit(0)
} 
} 
} if __name__ == '__main__':
} main()
 
> * dns_request.py
> * https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_request.py
> * first bug:
> * request file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request1
> * response file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response1
> * second bug:
> * request file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request2
> * response file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response2
> * third bug:
> * request file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request3
> * response file: 
> https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response3
> 

This worked for me:

wget https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_server.py
wget https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_request.py
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request1
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request2
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request3
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response3
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response2
wget https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response1


Upon "run" I get something like:

| $ python3 dns_request.py request3 5353
| b'12\x81\x80\x00\x01\x02\x00\x01\x06cert01\x07example...\x03ns2\xc0\x13'
| $


The how to reproduce question is answered.  Thanks.


However I don't understand the problem.

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

[zhangJiangyu via Dnsmasq-discuss]

On Sat, Nov 12, 2022 at 04:15:38PM +0800, Geert Stappers via Dnsmasq-discuss 
wrote:
> On Sat, Nov 12, 2022 at 10:30:09AM +0800, ZhangJiangyu 张江瑜 via 
> Dnsmasq-discuss wrote:
> > Hi,
> > 
> > Description
> > 
> > When the DNS forwarder iteratively queries the malicious domain name
> > server, it returns some malformed dns packets, and dnsmasq returns the
> > packet to the client without proper verification, which will give the
> > user a distrust or malicious data.  Other authoritative dns servers
> > have done correct verification.  there are three bugs below, you can
> > start a fake domain name server locally and return specific data.
> > 
> > Steps to reproduce
> > 
> > 1、Turn on a fake name server and return a specific payload.

> How?

Hi,

Thanks to Geert Stappers for the advice on replying to the maillist.

You need a few steps to reproduce:

* Run the command (sudo python3 dns_server.py "response filename path") to 
listen on port 53. This will start a fake dns server, receive the request, and 
return the result.
* Start the dnsmasq software to listen on port 5353.
* The configuration file is as follows:
  "port=5353
   no-daemon
   no-resolv
   server = 127.0.0.1
   bind-interfaces
   no-hosts"
* Run the command (./dnsmasq -C ./dnsmasq.conf) to start the dnsmasq.
* Run the command (python3 dns_request.py "request filename path" 5353) to send 
the request, dnsmasq will forward the request to our fake dns server, return 
the message and then return it to the client.
* Analyze the message returned to the client, you will find that there is a 
problem with the message, and the correct verification is not done.

Next, I will give the download link of the corresponding python script, request 
file and response file, which can be reproduced after downloading.

* dns_request.py
* https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_request.py
* dns_server.py
* https://643684107.oss-cn-beijing.aliyuncs.com/dns/dns_server.py
* first bug:
* request file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request1
* response file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response1
* second bug:
* request file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request2
* response file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response2
* third bug:
* request file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/request3
* response file: 
https://qu-hexo-static.oss-cn-hangzhou.aliyuncs.com/ping/response3

Thanks,
P1n9
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers via Dnsmasq-discuss]

On Sat, Nov 12, 2022 at 10:30:09AM +0800, ZhangJiangyu 张江瑜 via Dnsmasq-discuss 
wrote:
> Hi,
> 
> Description
> 
> When the DNS forwarder iteratively queries the malicious domain name
> server, it returns some malformed dns packets, and dnsmasq returns the
> packet to the client without proper verification, which will give the
> user a distrust or malicious data.  Other authoritative dns servers
> have done correct verification.  there are three bugs below, you can
> start a fake domain name server locally and return specific data.
> 
> Steps to reproduce
> 
> 1、Turn on a fake name server and return a specific payload.

How?




Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

[ZhangJiangyu 张江瑜 via Dnsmasq-discuss]

Hi,

Description

When the DNS forwarder iteratively queries the malicious domain name server, it 
returns some malformed dns packets, and dnsmasq returns the packet to the 
client without proper verification, which will give the user a distrust or 
malicious data.  Other authoritative dns servers have done correct 
verification.  there are three bugs below, you can start a fake domain name 
server locally and return specific data.

Steps to reproduce

1、Turn on a fake name server and return a specific payload.
2、start dnsmasq. The configuration options are as follows：
```python


port=53
no-daemon
no-resolv
server = 127.0.0.1
bind-interfaces
no-hosts

```

3、Send the corresponding dns request.





First bug


When the query class type is 0x01, the returned answer type is the wrong class 
name in the answer, which can be forwarded to the client. The wrong class type 
includes 0xdf01, 0x2001, 0x4001, 0x0801, 0x1001, 0x0401, 0x0201, 0x0101, 
0x0081, 0x0041, 0x0021, 0x0011, 0x0009, 0x0005, 0x0003, 0xetc. The rcode of 
the dnsmasq returned packet is 0.

Expected/Actual behavior:

bind，maradns，knot-resolver，pdns all return the response packets with rcode 2.

Reproduce data：
The first four bytes are the length.
request1
response1

Second bug

When there is an error in the domain name of the answer record, dnsmasq returns 
bad packets to the client. The rcode of the dnsmasq returned packet is 0.

Expected/Actual behavior:

bind，maradns,  pdns all return the response packets with rcode 2. knot-resolver 
return the response packets with rcode 3.

Reproduce data：
The first four bytes are the length.
request2
response2

Third bug

When the DNS packet returned by the domain name server has redundant data, it 
is not detected. The rcode of the dnsmasq returned packet is 0.

Expected/Actual behavior:

bind，maradns,  pdns all return the response packets with rcode 2. knot-resolver 
return the response packets with rcode 3.

Reproduce data：
The first four bytes are the length.
request3


response3




Thanks

P1n9

Zhejiang University___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss