Bug 2087575 (CVE-2022-1183) - CVE-2022-1183 bind: Destroying a TLS session early causes assertion failure
Summary: CVE-2022-1183 bind: Destroying a TLS session early causes assertion failure
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2022-1183
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: https://kb.isc.org/docs/cve-2022-1183
Whiteboard:
Depends On:
Blocks: 2087576
TreeView+ depends on / blocked
 
Reported: 2022-05-18 04:47 UTC by Sandipan Roy
Modified: 2022-05-19 14:57 UTC (History)
13 users (show)

Fixed In Version: bind 9.18.3
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in BIND due to a reachable assertion triggered if a TLS connection to a configured HTTP TLS listener with a defined endpoint is destroyed too early. This flaw allows a remote attacker to trigger a denial of service condition on the targeted system.
Clone Of:
Environment:
Last Closed: 2022-05-19 13:34:05 UTC


Attachments (Terms of Use)

Description Sandipan Roy 2022-05-18 04:47:31 UTC
An assertion failure can be triggered if a TLS connection to a configured http TLS listener with a defined endpoint is destroyed too early.
On vulnerable configurations, the named daemon may, in some circumstances, terminate with an assertion failure. Vulnerable configurations are those that include a reference to `http` within the `listen-on` statements in their `named.conf`. TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH), but configurations using   DoT alone are unaffected.

Versions affected: BIND 9.18.0 -> 9.18.2 and 9.19.0 of the BIND 9.19 development branch

Comment 1 Vicky Risk 2022-05-18 06:17:20 UTC
@saroy

This issue was pre-disclosed to RedHat under embargo until we published it. We have an excellent track record of notifying you when we lift the embargo, and we did explicitly request that you not disclose prematurely.

"ISC would like to make you aware of an upcoming security disclosure,
scheduled for Wednesday May 18, 2022, covering one high-severity
BIND vulnerability.  Please consider this information confidential
and under embargo until ISC publicly announces the vulnerability
on the disclosure date."

This is why the release notes, for example, are a *private* link. Even though this is the day when we had planned to publish this vulnerability, we have not yet published it, and therefore RedHat has disclosed it without authorization. 

Please do not do this. 

Victoria Risk
Product Manager and Incident Manager for this issue.

Comment 3 Vicky Risk 2022-05-18 08:18:14 UTC
Sandipan,

In that case we may need to reconsider this policy. We ask you to respect the embargo until we publish in case we don't, in fact, publish on the date planned, which sometimes does happen. 

Regards,

Vicky Risk

Comment 4 Vicky Risk 2022-05-18 10:15:10 UTC
Sandipan,

I do understand that you may have an internal process that just looks at the planned disclosure date, and does not consider whether the source developer has announced the CVE yet. If that is the official RedHat policy, that you disclose regardless of the publication by the developer, then we just need to know that so we don't pre-disclose to you. On the other hand, if this was a mistake, or somehow our communication was unclear, it would be helpful to know that.

In this case this was not a very serious vulnerability, but had it been, and had we needed to reschedule the release, this could have been a significant breach. It may not seem like a problem to you, but we put quite a bit of effort into careful disclosure and would appreciate some feedback about how we can avoid this in the future. 

Regards,

Vicky Risk

Comment 8 Petr Menšík 2022-05-18 12:37:00 UTC
(In reply to Vicky Risk from comment #4)
> Sandipan,
> 
> I do understand that you may have an internal process that just looks at the
> planned disclosure date, and does not consider whether the source developer
> has announced the CVE yet. If that is the official RedHat policy, that you
> disclose regardless of the publication by the developer, then we just need
> to know that so we don't pre-disclose to you. On the other hand, if this was
> a mistake, or somehow our communication was unclear, it would be helpful to
> know that.
> 
> In this case this was not a very serious vulnerability, but had it been, and
> had we needed to reschedule the release, this could have been a significant
> breach. It may not seem like a problem to you, but we put quite a bit of
> effort into careful disclosure and would appreciate some feedback about how
> we can avoid this in the future. 
> 
> Regards,
> 
> Vicky Risk

I am very sorry for the way this announce were handle. We value prelimitary announcements very highly and they are important for us. I do not think this were handled according our own policy and I am sorry for it. I think it was a mistake of an individual after previous person handling those kind of issues got promoted to higher position. We are taking steps to prevent similar issues next time. Please accept our humble appologies.

Especially because we leaked issue which does not affect any our product. We still have 9.18 only in preparation for Fedora Rawhide and devel release is not yet packaged in any production repository. All we can do with this report today is closing it with NOTABUG.

Comment 13 Ondřej Surý 2022-05-18 15:45:45 UTC
(In reply to Petr Menšík from comment #8)
> (In reply to Vicky Risk from comment #4)
> > Sandipan,
> > 
> > I do understand that you may have an internal process that just looks at the
> > planned disclosure date, and does not consider whether the source developer
> > has announced the CVE yet. If that is the official RedHat policy, that you
> > disclose regardless of the publication by the developer, then we just need
> > to know that so we don't pre-disclose to you. On the other hand, if this was
> > a mistake, or somehow our communication was unclear, it would be helpful to
> > know that.
> > 
> > In this case this was not a very serious vulnerability, but had it been, and
> > had we needed to reschedule the release, this could have been a significant
> > breach. It may not seem like a problem to you, but we put quite a bit of
> > effort into careful disclosure and would appreciate some feedback about how
> > we can avoid this in the future. 
> > 
> > Regards,
> > 
> > Vicky Risk
> 
> I am very sorry for the way this announce were handle. We value prelimitary
> announcements very highly and they are important for us. I do not think this
> were handled according our own policy and I am sorry for it. I think it was
> a mistake of an individual after previous person handling those kind of
> issues got promoted to higher position. We are taking steps to prevent
> similar issues next time. Please accept our humble appologies.
> 
> Especially because we leaked issue which does not affect any our product. We
> still have 9.18 only in preparation for Fedora Rawhide and devel release is
> not yet packaged in any production repository. All we can do with this
> report today is closing it with NOTABUG.

Hi @pemensik

Comment 14 Vicky Risk 2022-05-18 15:55:31 UTC
I can see you have updated the issue with the published Advisory URL now https://kb.isc.org/docs/cve-2022-1183 .

If you guys would like to avoid publishing this back and forth with us over the disclosure, it is fine with us if you just close it as NOT A BUG and leave it private. I don't think there is any way for me to remove my comments but I have no interest in embarrassing you if this was all an error. 

Vicky

Comment 15 Petr Menšík 2022-05-18 16:08:53 UTC
Release notes link:
https://downloads.isc.org/isc/bind9/9.18.3/doc/arm/html/notes.html#security-fixes

(In reply to Vicky Risk from comment #14)
> I can see you have updated the issue with the published Advisory URL now
> https://kb.isc.org/docs/cve-2022-1183 .
> 
> If you guys would like to avoid publishing this back and forth with us over
> the disclosure, it is fine with us if you just close it as NOT A BUG and
> leave it private. I don't think there is any way for me to remove my
> comments but I have no interest in embarrassing you if this was all an
> error. 
> 
> Vicky

I cannot delete any comments, but can make any comments private, visible only to redhat people. Not sure we should hide everything, will leave it for someone else to review.
Adding also link to release notes after it is released. Cannot link non-public gitlab issue.

Comment 17 Product Security DevOps Team 2022-05-19 13:34:03 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-1183


Note You need to log in before you can comment on or make changes to this bug.