RHEL9+, RSASHA1 and CVE-2025-8677

[Petr Menšík]

Hello Bjørn.

No. Algorithm 5 and 7 are skipped earlier and should never reach the 
code affected.

If the zone is signed only by SHA1 based algorithm, then it will be 
considered insecure after receving DS record for it. It should not even 
request DNSKEY for such zone and should not call any cryptographic 
functions. Keys should be skipped even if zone would be signed by 
multiple algorithms. Although I think it brings no benefit to dual sign 
with the weakest possible algorithm and I hope nobody does it.

I think this should affect only special cases considered supported 
algorithm (ie. not 5 or 7 on RHEL9+) and having special crafted DNSKEYs. 
Common signed zone would not trigger any of this, it would have to be 
something crafted to trigger unfixed code.

No crypto policy will change any of this, you do not have to lower your 
security defaults to avoid that.

Please wait few days, proper fixed are on the way!

On 31/10/2025 12:37, Bjørn Mork wrote:
> Time to re-evaluate the default SHA1 policies on RHEL...
>
> Quoting fromhttps://bind9.readthedocs.io/en/v9.20.15/notes.html#security-fixes
>
>   DNSSEC validation fails if matching but invalid DNSKEY is found. (CVE-2025-8677)
>
>   Previously, if a matching but cryptographically invalid key was
>   encountered during DNSSEC validation, the key was skipped and not
>   counted towards validation failures. named now treats such DNSSEC keys
>   as hard failures and the DNSSEC validation fails immediately, instead of
>   continuing with the next DNSKEYs in the RRset.
>
> IIUC, this means that any zone with a RSASHA1 key will now fail
> validation on Redhat systems using default policies, even if other keys
> are present.
>
> Is that correct?  Is it intentional?
No, the description is intentionally a little vague to not help 
attackers misusing known problem. But attack vector is not this simple 
AFAIK.
>
> If correct, then I believe it will break a number of zones with leftover
> RSASHA1 keys and signatures. Anyone still having such keys in their
> zones should purge them ASAP.  And resolver operators running BIND on
> RHEL9 should consider running
>
>   update-crypto-policies --set DEFAULT:SHA1
>
> to prevent unexpected failures.
>
>
> Bjørn
>
-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20251031/48b76458/attachment-0001.htm>