Fully automated DNSSEC with BIND 9.16

[Petr Menšík]

For CVEs, we have own site listing each and what is affected, what is 
not and whether fix is already available. CVE-2022-3924 [1] is not yet 
released in RHEL. Of course if you look into upstream notes to check 
what we have fixed in our distribution, it won't work well. Watching 
your own distribution announces might help too, such as centos-announce 
list [2].

[1] https://access.redhat.com/security/cve/CVE-2022-3924
[2] 
https://lists.centos.org/pipermail/centos-announce/2023-March/thread.html

On 18. 04. 23 9:20, Havard Eidnes wrote:
>> You do not have to sift through lists.
> That depends entirely what one wants to do.  I see a couple of
> scenarios where that may be required:
>
> 1) Let's say someone has flagged to you as a BIND administrator that
>     your BIND installatin is susceptible to CVE-2022-3924.  This
>     could be done via an "external scan" and based on the BIND
>     version returned (if your BIND is configured to reveal such
>     details), or via other means.  How do you as an administrator
>     figure out if the version you actually run has the fix for this
>     CVE included?
>
>     From the BIND change log, I can see
>
>          --- 9.16.37 released ---
>
> 6067.   [security]      Fix serve-stale crash when recursive clients soft quota
>                          is reached. (CVE-2022-3924) [GL #3619]
>
>     and if I run straight "upstream" code, it's fairly straight-
>     forward to upgrade to this version, modulo, of course, the fact
>     that this involves building it from source.
>
>     On the other hand, looking at a version produced by a package
>     maintainer (RedHat, Debian, ...), and where the package
>     maintainer insists on sticking with whatever base version they
>     started from (strictly based on timing, in all probability) and
>     selectively applying patches, it will be much harder to figure
>     out whether the fix is actually included.  And ... if the fix is
>     indeed included, you'll as administrator in all probability have
>     to mark the issue as "false positive" after having assured
>     yourself that the fix is included.  However, getting to this
>     assurance can be quite a bit of work.
>
> 2) You will end up with a somewhat similar scenario for
>     non-security-related functionality fixes -- you may hit a
>     problem which has been fixed upstream since your distributor
>     forked off BIND, and you may be able to find the entry for the
>     fix in BIND's upstream change log, but figuring out if that
>     fix is indeed included in the code you run will make it
>     necessary to rummage through the "patch list" of the
>     package administrator.

Yes, that indeed is a bit tiresome. Our bugs often reference upstream 
bugs if they fix them by upstream change backport. Or they are at least 
related. But I do not know if our bugs can be searched by upstream bug 
reference. It makes sense it should be possible and useful in few cases. 
Useful especially for community distributions, because our customers can 
just ask our support and they try to find it also in upstream issues. 
And requests to include that fix. But I guess filling duplicate bugs is 
not what we engineers would like, just because they were unable to find 
already requested or fixed issue. Yes, we should try to improve that, 
thank you for a suggestion!

It seems it can work on issues.redhat.com somehow, but 
bugzilla.redhat.com does not offer simple way to search by upstream 
issue link. Even if that is included in our bug.

>> We provide quite detailed git branch with each change we
>> make. It has references to bugs related too. I admit changes
>> listed in release notes of bind9 releases are nicer. But we do
>> not hide what and why we do changes, publish them quite nice
>> way for c9s [1]. It would be the same c8s as well soon.
>>
>> For important changes they are mentioned in release notes of the minor
>> release. But I admit we do not mention explicitly each bug we fix the
>> way ISC does. It would make our documentation unreadable.
>>
>> In any case, even if we fall behind a couple of releases, any our
>> packages of bind 9.16 are capable of automated DNSSEC deployment just
>> fine. Sure, even we do not support it for RHEL7 or older.
>>
>> [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s
> I certainly do appreciate that this is a considerable effort, and
> that you do this as well as you can with all good intentions.  Now,
> even though the change log is available as stated (which is good, of
> course) does not necessarily make it easy to find.  And ... solving
> the above two issues still requires a detailed sift through the
> lists.
>
> Regards,
>
> - Håvard

Sure, in the end there is always some work required to do. We could 
improve some things to require less work, but cannot eliminate it 
altogether. I guess that is what you have meant.

Regards,
Petr

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