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

[Mark Andrews <[e-mail]>]

> On 16 Apr 2021, at 04:52, Paul Vixie <[e-mail]> wrote:
> 
> On Thu, Apr 15, 2021 at 05:46:29PM +1000, Mark Andrews wrote:
>>> On 15 Apr 2021, at 17:28, Paul Vixie <[e-mail]> wrote:
>>> 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.
> 
>> The freebsd code still isn't correct "if (0xc0 & len) {" !=
>> "if ((0xc0 & len) == 0xc0) {"
>> which is the correct test for a compression pointer.
> 
> this certainly is not correct, but doesn't seem related to the forescout
> report.

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."

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]