On Tue, May 19, 2020 at 11:59:05AM +0100, Luca Boccassi wrote:
> On Tue, 2020-05-19 at 12:51 +0200, Moritz Mühlenhoff wrote:
> > On Tue, May 19, 2020 at 10:02:46AM +0100, Luca Boccassi wrote:
> > > On Thu, 14 May 2020 22:57:44 +0100 Luca Boccassi <
> > > [email protected]
> > > > wrote:
> > > > On Thu, 2020-05-14 at 18:50 +0100, Luca Boccassi wrote:
> > > > > Package: openconnect
> > > > > Version: 6.00-1
> > > > > Severity: important
> > > > > Tags: security
> > > > >
> > > > > Openconnect is affected by a buffer overflow in certificate handling,
> > > > > that goes back at least to 6.00-1 (old-old-stable).
> > > > >
> > > > > Fixed upstream by:
> > > > >
> > > > >
> > > https://gitlab.com/openconnect/openconnect/-/merge_requests/108
> > >
> > > > Dear security team,
> > > >
> > > > I uploaded to old-old-stable on request from the LTS team. How would
> > > > you like to handle stable and old-stable?
> > >
> > > Ping. Should I do an upload to security-master for buster-security and
> > > stretch-security?
> >
> > It's not really clear to me why this was assigned a CVE ID, this doesn't
> > appear to cross any reasonable trust boundary. Certificates need to come
> > from a trusted source, otherwise you have many other insecurities at hand.
> >
> > This appears to be "just a bug" (which would seem to reach the bar for
> > being fixed in a point update), but I can't see why this would need a DSA.
> >
> > I might totally miss something, ofc. So please correct me if I'm wrong :-)
> >
> > Cheers,
> > Moritz
>
> Hi,
>
> The upstream maintainer agrees that perhaps a CVE was not warranted.
> The only way this check could be done on an somewhat-external
> certificate is if it came from a PKCS#11 token, but it's pretty far
> fetched.
>
> Release notes say:
>
> "This release is brought to you by CVE-2020-12823; a buffer overflow
> when obtaining a pretty name to describe local certificates, when built
> against GnuTLS. Note that this isn't used for remote certificates; this
> is all local (client cert and supporting CAs provided locally) so not
> easily remotely triggerable."
Thanks for doublechecking!
As such, we don't need a DSA. You could target this for a point update
or we can stuff it in some git branch and piggyback on a potential
future DSA in case there's a DSA-relevant issue at some point?
Cheers,
Moritz
