Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1018347

Bug#965184: CVE-2020-15719

From Ryan Tandy <ryan@nardis.ca>
Newsgroups linux.debian.bugs.dist
Subject Bug#965184: CVE-2020-15719
Date 2020-07-17 18:20 +0200
Message-ID <AtBfA-6FD-11@gated-at.bofh.it> (permalink)
References <Atw6d-3s9-3@gated-at.bofh.it> <Atw6d-3s9-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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?

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#965184: CVE-2020-15719 Moritz Muehlenhoff <jmm@debian.org> - 2020-07-17 12:50 +0200
  Bug#965184: CVE-2020-15719 Ryan Tandy <ryan@nardis.ca> - 2020-07-17 18:20 +0200
    Bug#965184: CVE-2020-15719 Moritz Mühlenhoff <jmm@inutil.org> - 2020-07-22 16:40 +0200

csiph-web