Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?

[Kurt Jaeger]

Hi!

In the light of the recent exim security issues[1,2]
I'm trying to find out if bind 9.18.19, if used as resolver,
does enough validation to shield exim instances from CVE-2023-42119 ?

As details and reproducers for the CVE are not available, this is a
more general question. Pointers on where I can read more about it
are highly appreciated!

There are probably two aspects to validation:
- Validating DNSSEC (the more common use case of validation)
- Validating DNS request/replies in general (bailiwick, cache polution etc).

[1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html
[2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/

-- 
p...@opsec.eu+49 171 3101372Now what ?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: inline-signing breaks nsdiff.

[Petr Špaček]

On 01. 10. 23 21:10, Björn Persson wrote:

I find that when both inline-signing and update-policy are in use, I
can't detect race conditions with the method described in RFC 2136
section 5.7, which nsdiff uses.

It seems that a serial number specified in a prerequisite of an update
is compared to the unsigned version of the zone, but the serial number
retrieved with a SOA or AXFR query is from the signed version. Thus the
update fails when BIND has renewed some RRSIG records and changed the
signed serial number.

Checking prerequisites against records that can't be looked up seems
like a bad idea to me.

In a zone that uses dnssec-policy and relies on the default value of
inline-signing, the method in RFC 2136 section 5.7 will stop working on
upgrade to BIND 9.20, as inline-signing will then be switched on by
default, if I understand correctly. I have set "inline-signing no;"
explicitly in all my zones to prevent future breakage.


I can see what you mean. Please open an issue in our Gitlab:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new
... and we will discuss what can be done about it.

It would be great if you add step-by-step reproducer for the problem. It 
will greatly help us to write automated test for it.


Thank you for your time.

--
Petr Špaček
Internet Systems Consortium
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?

[Petr Špaček]

On 02. 10. 23 11:06, Kurt Jaeger wrote:

Hi!

In the light of the recent exim security issues[1,2]
I'm trying to find out if bind 9.18.19, if used as resolver,
does enough validation to shield exim instances from CVE-2023-42119 ?

As details and reproducers for the CVE are not available, this is a
more general question. Pointers on where I can read more about it
are highly appreciated!

There are probably two aspects to validation:
- Validating DNSSEC (the more common use case of validation)
- Validating DNS request/replies in general (bailiwick, cache polution etc).

[1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html
[2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/


It's impossible to judge from the (lack of) details provided. Sorry!

--
Petr Špaček
Internet Systems Consortium
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: inline-signing breaks nsdiff.

[Björn Persson]

Petr Špaček wrote:
> Please open an issue in our Gitlab:

Done:
https://gitlab.isc.org/isc-projects/bind9/-/issues/4352

Björn Persson


pgp3GzBYDpAWV.pgp
Description: OpenPGP digital signatur
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KSAP - How to manually rollover keys documentation?

[Eddie Rowe]

I appreciate your email.  I thought that was the process but the older version 
of the ARM I was using (matches my version) didn't have that nice section.  So 
I will need to be sure to look in the current document when scratching my head 
as someone is making some nice additions and improvements to the documentation!

From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: Friday, September 29, 2023 5:01 PM
To: bind-users@lists.isc.org 
Subject: Re: KSAP - How to manually rollover keys documentation?

On 28/09/23 10:02, Eddie Rowe wrote:
I am using the nifty feature of the KASP in 9.16.23, but I cannot seem to 
locate documentation on how to manually rollover keys in case this is needed in 
the future. The documentation is excellent as far as discussing the steps 
involved for the manual or semi-automatic but I am not seeing the steps and 
tools you would use to rollover manually when using the KASP feature.  Am I 
overlooking another document or KB article on this topic?

Hi Eddie.

I wonder if the information you're looking for is here: 
https://bind9.readthedocs.io/en/latest/chapter5.html#key-rollover

Specifically the following sentence:

To roll a key sooner than scheduled, or to roll a key that has an unlimited 
lifetime, use: rndc dnssec -rollover -key 12345 
dnssec.example..

Nick.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KASP Key Rollover: ZSK Disappears Immediately

[Eddie Rowe]

I appreciate the feedback.  I did make sure the ZSK is omnipresent and the 
issue still happens so it might be that my attempt to take the default policy 
and bring it down to 1 day to hurry along testing.  I will see if I can find 
any test policies in the list archives and failing that use the default one 
with a greater amount of patience.

From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: Friday, September 29, 2023 5:37 PM
To: bind-users@lists.isc.org 
Subject: Re: KASP Key Rollover: ZSK Disappears Immediately


Sorry I just realised that all that waffle about DS records is only relevant 
for KSKs (and CSKs), not ZSKs. So please disregard that. :-P


But I think the "rumoured" vs. "omnipresent" thing is still relevant and is the 
most likely explanation for why the old ZSK doesn't stick around. I can only 
assume that the reason you have rumoured state is because you are trying to 
roll your ZSK to soon after the previous ZSK rollover? Have you checked the 
various timing settings in the KASP definition?


Nick.



On 30/09/23 11:32, Nick Tait via bind-users wrote:
On 29/09/23 12:05, Eddie Rowe wrote:
When I perform a ZSK key rollover the existing ZSK disappears immediately so 
not sure what I am missing when using the KASP to manage key rollover.  The 
state for the keys looks good and for this test I have TTL set to 1 hour..  But 
why does dig not show me both DNSKEY records for the ZSK after I initiate the 
rollover when there should be overlap as described in Automatic DNSSEC Zone 
Signing Key rollover explained (isc.org)?

Bind 9.16.23 which seems to be the newest release provided by my distribution.  
I reviewed the ARM for notes for newer releases in the 9.16 branch and did not 
see mention of any rollover bugs or for dig.

  1.   Here is the key info from dig for ZSK key 15465 at 17:17.

# dig @localhost myexample.com DNSKEY +multi

; <<>> DiG 9.16.23-RH <<>> @localhost myexample.com DNSKEY +multi
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7c2a0e61926d2d3a01006515fb68eef12b631ca40c20 (good)
;; QUESTION SECTION:
;myexample.com. IN DNSKEY

;; ANSWER SECTION:
myexample.com.  3600 IN DNSKEY 257 3 13 (
20agIXl9sQCo00yiHHviYWZG8TvVmDoVxPJwO3mlcwxB
le7UNrzNQaeukC6teT4XrqYflqDxcM6d9L/mtREIKA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 31296
myexample.com.  3600 IN DNSKEY 256 3 13 (
AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq6
78nSI3DyM+1t91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 15465

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 17:17:12 CDT 2023
;; MSG SIZE  rcvd: 230


  1.   Here is the info from the key as far as state goes.

# more Kmyexample.com.+013+15465.key
; This is a zone-signing key, keyid 15465, for myexample.com.
; Created: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Publish: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Activate: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Inactive: 20231127221438 (Mon Nov 27 16:14:38 2023)
; Delete: 20231207231938 (Thu Dec  7 17:19:38 2023)
myexample.com. 3600 IN DNSKEY 256 3 13 
AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq678nSI3DyM+1t 
91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==

# more Kmyexample.com.+013+15465.state
; This is the state of key 15465, for myexample.com.
Algorithm: 13
Length: 256
Lifetime: 5184000
KSK: no
ZSK: yes
Generated: 20230928221438 (Thu Sep 28 17:14:38 2023)
Published: 20230928221438 (Thu Sep 28 17:14:38 2023)
Active: 20230928221438 (Thu Sep 28 17:14:38 2023)
Retired: 20231127221438 (Mon Nov 27 16:14:38 2023)
Removed: 20231207231938 (Thu Dec  7 17:19:38 2023)
DNSKEYChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
ZRRSIGChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
DNSKEYState: rumoured
ZRRSIGState: rumoured
GoalState: omnipresent

I suspect that the crucial detail above is "DNSKEYState: rumoured". This 
suggests that the last ZSK rollover hasn't been fully completed.

Before starting a rollover it is a good idea to make sure the ZSK that you are 
retiring is in an "omnipresent" state.


The usual reason that the key isn't in omnipresent state is because BIND is 
still waiting for the corresponding DS record to be published and available in 
the parent zone. BIND 9.16 only knows if the DS record is published if you've 
set up parental-agents, or if you've explicitly told it using rndc. (BTW BIND 
9.19 introduces new default behaviour which means you don't need to set 
parental-agents in order for it to figure this out.)


Have a look here: 
https://bind9.readthedocs