Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
Hi, On Wed, May 20, 2020 at 09:22:11AM +0100, Luca Boccassi wrote: > On Tue, 2020-05-19 at 19:34 +0200, Moritz Mühlenhoff wrote: > > 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 < > > > > > bl...@debian.org > > > > > > 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 > > Queueing for the next time around sounds like a good idea - pushed to > the debian/buster branch. With the fact that procedures for updates via point releases have been improved, it would be as well just be an option to upload for the next buster point release and have it already queued. Just as additional comment to the above. Regards, Salvatore
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
On Tue, 2020-05-19 at 19:34 +0200, Moritz Mühlenhoff wrote: > 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 < > > > > bl...@debian.org > > > > > 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 Queueing for the next time around sounds like a good idea - pushed to the debian/buster branch. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
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 < > > > bl...@debian.org > > > > 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
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
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 < > > bl...@debian.org > > > 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." -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
On Tue, May 19, 2020 at 10:02:46AM +0100, Luca Boccassi wrote: > On Thu, 14 May 2020 22:57:44 +0100 Luca Boccassi < > bl...@debian.org > > 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
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
On Thu, 14 May 2020 22:57:44 +0100 Luca Boccassi < bl...@debian.org > 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? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
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? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)
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 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
