Subject: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Apr 2021 11:01:42 +0200

The Name:Wreck compression pointer issue
<https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations>
illustrates the implementation problems of DNS. I just find that there
is an Internet-Draft, draft-dashevskyi-dnsrr-antipatterns, discussing
these problems. Seems interesting.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Apr 2021 11:19:05 +0200

On Wed, Apr 14, 2021 at 11:01:42AM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> <https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations>

Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS
Proxy Implementation Guidelines" to replace the MAY in section 6.3 by
a MUST. I think that the reason there is currently a MAY is not
because RFC 5625 finds invalid compression pointers acceptable but
simply because some proxies may not perform a full parsing of the RR
in the sections.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Apr 2021 14:47:06 +0200

> The Name:Wreck compression pointer issue

Also
<https://www.scmagazine.com/home/security-news/vulnerabilities/namewreck-is-the-latest-collision-between-tcp-ip-and-the-standards-process/>
talks about what IETF should do. (The article contains several errors
about the RFC process.)

> “I mean I don’t want to be the one telling the [Internet Engineering
> Task Force] how to do their work. Things have worked for more than
> 40 years on the internet because of the RFC systems,” he said. “But
> indeed, I do believe that it’s time that we think of an
> alternative.”

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2021 09:36:40 -0400

>> The Name:Wreck compression pointer issue

I skimmed his very wordy paper and saw that all of the bugs he reported that affect software
I use were fixed a year ago.

We find that IoT stuff is crud.  This is not news and I don't think it's something that RFCs either caused or could fix.

On the other hand, all of the sloppy coding people use to handle compressed names is embarassing.

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 14 Apr 2021 17:57:35 +0400

> > indeed, I do believe that it’s time that we think of an

I think that the authors of the draft could consult this ?
https://www.ietf.org/standards/rfcs/vulnerabilities/

>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Apr 2021 22:17:32 +0100

> compressed names is embarassing.

I don't think it's entirely fair to blame the coders who make these
mistakes, because a very large number of excellent programmers have made a
mess of DNS name decompression. When I find out about new DNS code the
first thing I do is look at the name parser to see if it successfully
avoids these traps and pitfalls, because it's a good indication that the
programmer has learned from their own or others' mistakes, or has much
greater than average ability to write attack-resistant parsers.

It seems worthwhile to try to help future coders not to mess it up.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Gibraltar Point to North Foreland: Northerly or northeasterly 3 to 5.
Smooth or slight becoming slight or moderate. Showers. Good.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Apr 2021 07:19:27 +1000

> On 15 Apr 2021, at 07:17, Tony Finch <[email-masked]> wrote:
> 

Adding test vectors would help, especially broken vectors.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 15 Apr 2021 09:12:57 +0200

On 4/14/2021 11:19 PM, Mark Andrews wrote:
>> On 15 Apr 2021, at 07:17, Tony Finch<[email-masked]>  wrote:
>>
>> John Levine<[email-masked]>  wrote:
>> f.anthony.n.finch<[email-masked]>   https://dotat.at/

+1. That would be a pretty good way for the IETF to help clean the mess. 
That, and maybe a DNS site that would serve the test vectors.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2021 07:28:03 +0000

> > > mistakes, because a very large number of excellent programmers have
> > > made a mess of DNS name decompression. ...

i shipped the crap in question as late as 1998, and excellence wasn't the
problem. in this field at that time, crap was the norm, and this crap was
better than most -- "excellent" if you will, by the standards of the day.

this is not that day, and while crap may still be an internet norm, it is
no longer excellent. here are some of the things you can be sure of:

1. somebody wrote or copied this code in C and didn't red-team it
2. somebody copied this code without tracking where they copied it from

so, freebsd was unfairly maligned in the forescout report on this event;
the bug was in their dhcp client, not their dns or "tcp/ip stack", and
had been fixed 20 years late but still six months ago.

everything else on that list was properly and fairly maligned, and ought
to be grounds to wonder what other code those vendors have written or
copied in C, without red-teaming it, and without tracking later changes.

> > > It seems worthwhile to try to help future coders not to mess it up.

as a technology action, sure. but we've got to stop writing crap generally
not just in decoders. that means red-teaming things before they go out,
and only dealing with vendors who can afford to do this. (C, having as it
does no bounds checking, allows any pointer to be wild -- So Expect That.)

"as long as people write parsers,
and connect them to the internet,
i'll have work." --anon

-- 
Paul Vixie

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Apr 2021 17:46:29 +1000

> On 15 Apr 2021, at 17:28, Paul Vixie <[email-masked]> wrote:
> 

The freebsd code still isn’t correct "if (0xc0 & len) {" != "if ((0xc0 & len) == 0xc0) {“
which is the correct test for a compression pointer.

The frustrating part is that it could have all been done safely with libresolv
rather than reinventing the wheel.  The pain had already been taken with libresolv.

---

From: "John R Levine" <[email-masked]>
Date: 15 Apr 2021 11:39:39 -0400

> That, and maybe a DNS site that would serve the test vectors.

In this case I think it's a reasonable idea but I echo jck's concern that 
test vectors can turn into de-facto standards, particularly when the tests 
and the text turn out not to exactly match.

On the other hand, is it valid for a DNS compression pointer to point 
forward in the message?  Why or why not?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Wellington, Brian" <[email-masked]>
Date: Thu, 15 Apr 2021 16:22:50 +0000

RFC 1035 says “prior occurance”, which would mean no.

4.1.4. Message compression

In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message.  In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

Brian

> On Apr 15, 2021, at 8:39 AM, John R Levine <[email-masked]> wrote:
> 
>> +1. That would be a pretty good way for the IETF to help clean the mess. That, and maybe a DNS site that would serve the test vectors.
> 
> In this case I think it's a reasonable idea but I echo jck's concern that test vectors can turn into de-facto standards, particularly when the tests and the text turn out not to exactly match.
> 
> On the other hand, is it valid for a DNS compression pointer to point forward in the message?  Why or why not?
> 
> Regards,
> Please consider the environment before reading this e-mail. https://urldefense.com/v3/__https://jl.ly__;!!GjvTz_vk!Fjf42blj0yV8IPVN81l1DX083zhJ6EyGrExCUwvu4ak3_8pUW9kQBitxYWlLWe8$ 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!GjvTz_vk!Fjf42blj0yV8IPVN81l1DX083zhJ6EyGrExCUwvu4ak3_8pUW9kQBitxSq3w_EQ$

---

From: Christian Huitema <[email-masked]>
Date: Thu, 15 Apr 2021 18:40:56 +0200

On 4/15/2021 5:39 PM, John R Levine wrote:

>> +1. That would be a pretty good way for the IETF to help clean the 
>> mess. That, and maybe a DNS site that would serve the test vectors.
>
> In this case I think it's a reasonable idea but I echo jck's concern 
> that test vectors can turn into de-facto standards, particularly when 
> the tests and the text turn out not to exactly match.

A test server could easily have a fuzz option...

> forward in the message?  Why or why not? 

I had to implement a packet parser a few years ago, and I rather 
naturally added a test that the pointers had to be backward. Not doing 
that looked like inviting trouble. I tested that on a fair number of 
root server traces and never found an issue. So I tend to think that's a 
fairly safe test.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2021 18:52:12 +0000

> The freebsd code still isn't correct "if (0xc0 & len) {" !=
> "if ((0xc0 & len) == 0xc0) {"

this certainly is not correct, but doesn't seem related to the forescout
report.

> The frustrating part is that it could have all been done safely with
> libresolv rather than reinventing the wheel.  The pain had already
> been taken with libresolv.

as you know, this was discussed internally at the time. when dhclient
took its copy of libresolv, these bugs were still present. i muchly
regret not releasing libresolv independent of BIND so that projects
who needed the code could add it as a dependency not a copy. "oops."

-- 
Paul Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Apr 2021 07:46:35 +1000

> On 16 Apr 2021, at 04:52, Paul Vixie <[email-masked]> wrote:
> 

While not identical is it related to this section of the report where reserved values are used incorrectly.  Below are being used to compute the label length incorrectly.  FreeBSD will use them to compute the compression pointer.  Neither behaviour is correct and impacts on future attempts to use those values for something else.  We have had bit string labels and proposals for local compression pointers.

"Another typical mistake with compression pointers that we have seen in the past (e.g., uIP and PicoTCP in AMNESIA:33) is to check only that either of the two most significant bits of a label length is 0b1. In this case, label lengths such as 0x80 and 0x40 will also be considered valid compression pointers. This violates RFC1035 (high bit combinations 10 and 01 are reserved for special use and must not be present in a domain name), and while this is not a vulnerability per se, it may be beneficial to attackers. For example, an intrusion detection system that has a rule for detecting invalid compression offsets may not flag specific malformed packets because 0x80 is not a compression pointer, but some vulnerable implementations treat this value as such."

---

From: Ray Bellis <[email-masked]>
Date: Fri, 16 Apr 2021 09:18:44 +0100

> simply because some proxies may not perform a full parsing of the RR

Yes, that was pretty much it.

Many DNS proxies / ALGs don't inspect the packet contents at all, so a
stronger generic requirement was not feasible.

(The suggested SERVFAIL response is wrong, I think.  It should've been
FORMERR)

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 16 Apr 2021 10:00:53 +0100

> stronger generic requirement was not feasible.

FWIW, I have formally requested that the authors withdraw the statement
in the paper's conclusion that infers that RFC 5625 is "too complex,
ambiguous or outdated".

They have utterly failed to comprehend that the scope and context of RFC
5625 was DNS Proxy / ALGs in home gateways and that it is not
appropriate to criticize it for not making normative requirements of
*every* DNS stack.  They simply were not in scope.

Ray

---

From: Tony Finch <[email-masked]>
Date: Sat, 17 Apr 2021 18:57:58 +0100

Paul Vixie <[email-masked]> wrote:
>
> i shipped the crap in question as late as 1998

I absolutely honestly wasn't thinking of your crap at all :-)

But your broader point about modern standards of excellence is well made.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Forties: Southeasterly 3 to 5, but variable 4 or less at times in
east. Smooth or slight becoming slight or moderate. Fair. Good.

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 20 Apr 2021 00:08:34 +0800

> stronger generic requirement was not feasible.
depends on use case ?
enterprise dns proxies may inspect, but home gateway proxies may not.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Apr 2021 17:13:50 +0100

On 19/04/2021 17:08, Lanlan Pan wrote:
> 
> 
> Ray Bellis <[email-masked] <mailto:[email-masked]>> 于2021年4月16日
> 周五 下午4:19写道：
> 

Yes, of course, although the latter were the primary target audience for
RFC 5625.

kind regards,

Ray