Bug 2071543 - Unbound fails resolution of any SHA-1 signed domain [rhel-9.1.0]
Summary: Unbound fails resolution of any SHA-1 signed domain [rhel-9.1.0]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: unbound
Version: 9.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
Jan Fiala
URL:
Whiteboard:
Depends On: 2070495 2087120
Blocks: 2077909 2135933
TreeView+ depends on / blocked
 
Reported: 2022-04-04 07:26 UTC by RHEL Program Management Team
Modified: 2022-11-15 11:09 UTC (History)
6 users (show)

Fixed In Version: unbound-1.13.1-13.el9
Doc Type: Bug Fix
Doc Text:
.Unbound no longer validates SHA-1-based RSA signatures Previously, OpenSSL did not validate SHA-1-based RSA signatures in the DEFAULT system-wide cryptographic policy. As a consequence, when Unbound tried to validate such signatures, the error from OpenSSL caused the resolution to fail. With this update, Unbound disables validation support of all RSA/SHA1 (algorithm number 5) and RSASHA1-NSEC3-SHA1 (algorithm number 7) signatures, which resolves the query. Note that this makes the result insecure under all system-wide cryptographic policies.
Clone Of: 2070495
: 2135933 (view as bug list)
Environment:
Last Closed: 2022-11-15 10:15:56 UTC
Type: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github NLnetLabs unbound issues 656 0 None closed [FR] Smart deprecation of SHA-1 signatures 2022-08-11 12:02:30 UTC
Github NLnetLabs unbound pull 660 0 None Merged Sha1 runtime insecure 2022-08-11 12:03:31 UTC
Gitlab redhat/centos-stream/rpms unbound merge_requests 12 0 None merged Disable altogether SHA-1 support 2022-08-11 12:02:15 UTC
Red Hat Issue Tracker RHELPLAN-117712 0 None None None 2022-04-04 07:41:06 UTC
Red Hat Product Errata RHSA-2022:8062 0 None None None 2022-11-15 10:16:20 UTC

Comment 2 Petr Menšík 2022-04-27 10:41:45 UTC 
I would like to modify this behaviour in unbound to follow crypto-policy settings. It has to disable SHA-1 validation under DEFAULT crypto-policy, but it should allow secure reply in DEFAULT:SHA1 policy.

Proposal to upstream were offered [1], but it did not trigger any response from them yet. Perhaps they think this is only our internal problem.

1. https://github.com/NLnetLabs/unbound/issues/656
Comment 7 Petr Menšík 2022-08-11 12:01:59 UTC 
With a rebase to recent 1.16.2 version, the build should be able to disable validation on DEFAULT policy, but keep it enabled in DEFAULT:SHA1 or LEGACY policies.
Comment 10 Petr Menšík 2022-08-25 18:24:27 UTC 
It seems the change I offered to upstream (and which is merged in this version) were not complete. I wanted algorithm 7 signatures to become (secure) when update-crypto-policies --set DEFAULT:SHA1 is used. But if I enable SHA-1 algorithm again, it fails in unittest.

Failing MR 17. Unit tests result has to be reviewed, maybe there is hidden issue. On the first glance resolution becomes secure on DEFAULT:SHA1 policy and insecure on DEFAULT policy, but I think we can postpone this dynamic switching to 9.2. Better to have always insecure SHA-1 signatures than resulting to SERVFAIL bogus results in a few cases.

[1] https://gitlab.com/redhat/centos-stream/rpms/unbound/-/merge_requests/17
Comment 13 errata-xmlrpc 2022-11-15 10:15:56 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: unbound security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8062
Note You need to log in before you can comment on or make changes to this bug.