Date: Wed, 20 Jan 2016 10:14:26 +0100 From: Florian Weimer <fweimer@...hat.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: CVE assignment request for security bugs fixed in glibc 2.23 On 01/20/2016 03:51 AM, cve-assign@...re.org wrote: > The MITRE CVE team generally can assign IDs for security-fix releases > of products where a notable upstream vendor has already made a final > determination of what issues are, from their perspective, > vulnerabilities that require customers to perform a product update. In glibc's case, it's more about changes which may deserve backports to distribution releases. > Based on the set of issues mentioned, however, we probably don't have > a shared understanding of what glibc bugs should be considered > vulnerabilities and what ones should be considered ordinary bugs. My understanding is shaped in part by your previous assignments. CVE-2015-1473 is a good example, where the stack usage accounting is off by a factor of four. We try to approach this differently on the glibc side, as explained here: <https://sourceware.org/glibc/wiki/Security%20Process> But this policy, requiring actual application impact for (say) denial-of-service vulnerabilities, does not match your past assignment practice, or indeed general industry expectations. Approaching this from a completely different angle: If glibc upstream marks certain bugs as potential backport material due to their security impact, without arranging for CVE assignment, how can we make such assignments happen in time for downstream security updates? I expected that you do not want Red Hat, Debian &c to assign CVE IDs for already public issues. Yet you have failed to provide such assignments when they were requested, leading to CVE-less security updates such as this one: <https://lists.debian.org/debian-lts-announce/2015/09/msg00011.html> > None of this is going to be resolved today, so here are the five CVE > IDs for the listed issues. Thanks, I will incorporate the assignments into the glibc bug tracker. We still have a backlog of a few dozen issues fixed in previous releases which are clearly vulnerabilities or have been referenced in downstream security advisories. We really should have a discussion about how to handle them. We can have it here, or in response to the multiple messages I sent last fall. Florian
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ