Bug#965184: CVE-2020-15719

[Ryan Tandy]

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?