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

Groups > linux.debian.bugs.dist > #1018308 > unrolled thread

Bug#965184: CVE-2020-15719

Back to article view | Back to linux.debian.bugs.dist

Contents

  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

#1018308 — Bug#965184: CVE-2020-15719

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

[toc] | [next] | [standalone]

#1018347

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?

[toc] | [prev] | [next] | [standalone]

#1018901

On Fri, Jul 17, 2020 at 09:07:57AM -0700, Ryan Tandy wrote:
> Control: tag -1 moreinfo
> 
> Hi Moritz, thanks for the report.

Sorry for the late reply, had a bunch of other issues pending.

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

Thanks.

> 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?

We should definitely follow upstream, I think Howards's reasoning makes
a lot of sense. I'll mark it as a non-issue in the Debian Security Tracker.

Cheers,
         Moritz

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web