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
@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.
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
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
(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.
(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
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
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.
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