CVE-2020-15719

Debian Bug report logs - #965184
CVE-2020-15719

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: CVE-2020-15719

Date: Fri, 17 Jul 2020 12:41:35 +0200

Source: openldap
Severity: important
Tags: security

Hi,
CVE-2020-15719 was assigned to an issue in OpenLDAP found by Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=1740070

The underlying OpenLDAP bug is restricted, though:
https://bugs.openldap.org/show_bug.cgi?id=9266

The patch applied by Red Hat is
https://git.centos.org/rpms/openldap/raw/67459960064be9d226d57c5f82aaba0929876813/f/SOURCES/openldap-tlso-dont-check-cn-when-bad-san.patch
bug given that 1740070 is restricted I'm not sure if it affects the
Debian OpenLDAP packages or not (as we sue GNUTLS instead of OpenSSL)

Cheers,
        Moritz

Message #10 received at 965184@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Moritz Muehlenhoff <jmm@debian.org>, 965184@bugs.debian.org

Subject: Re: Bug#965184: CVE-2020-15719

Date: Fri, 17 Jul 2020 09:07:57 -0700

Control: tag -1 moreinfo

Hi Moritz, thanks for the report.

On Fri, Jul 17, 2020 at 12:41:35PM +0200, Moritz Muehlenhoff wrote:
>CVE-2020-15719 was assigned to an issue in OpenLDAP found by Red Hat:
>https://bugzilla.redhat.com/show_bug.cgi?id=1740070
>
>The underlying OpenLDAP bug is restricted, though:
>https://bugs.openldap.org/show_bug.cgi?id=9266

The OpenLDAP ticket has now been made public.

>The patch applied by Red Hat is
>https://git.centos.org/rpms/openldap/raw/67459960064be9d226d57c5f82aaba0929876813/f/SOURCES/openldap-tlso-dont-check-cn-when-bad-san.patch
>bug given that 1740070 is restricted I'm not sure if it affects the
>Debian OpenLDAP packages or not (as we sue GNUTLS instead of OpenSSL)

The patch was rejected upstream, with the explanation that the current 
behaviour already conforms to RFC 4513. I haven't checked, but would 
assume the GnuTLS implementation probably behaves the same way.

RFC 6125 § 1.4 "Applicability" notes:

>This document also does not supersede the rules for verifying service 
>identity provided in specifications for existing application protocols 
>published prior to this document, such as those excerpted under 
>Appendix B.  However, the procedures described here can be referenced 
>by future specifications, including updates to specifications for 
>existing application protocols if the relevant technology communities 
>agree to do so.

No such update has occurred for LDAP (that I'm aware of), so I think 
Howard is correct that RFC 4513 is still authoritative.

There might be an argument to be made that the Common Name matching is 
described as something the implementation "may also" do, so we could 
tweak how it works without actually violating RFC 4513. However it's 
enough of a grey area (and a subtle enough difference) that I think I'd 
prefer to just follow upstream, especially if some existing setups might 
be depending on that behaviour (CN not duplicated in a SAN).

What do you think?

Send a report that this bug log contains spam.