> On 16 Apr 2021, at 04:52, Paul Vixie <p...@redbarn.org> wrote:
>
> On Thu, Apr 15, 2021 at 05:46:29PM +1000, Mark Andrews wrote:
>>> On 15 Apr 2021, at 17:28, Paul Vixie <p...@redbarn.org> 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: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
