[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150312181727.47D266C0055@smtpvmsrv1.mitre.org>
Date: Thu, 12 Mar 2015 14:17:27 -0400 (EDT)
From: cve-assign@...re.org
To: carnil@...ian.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: Gtk2 Perl Module: incorrect memory management in Gtk2::Gdk::Display::list_devices
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> A new upstream version of the Gtk2 Perl module was released (1.2495)
> fixing incorrect memory management in
> Gtk2::Gdk::Display::list_devices. Upstream commit is at
>
> https://git.gnome.org/browse/perl-Gtk2/commit/?id=4856da628ce37099b27b66a88141dc6daad693b0
>
> References:
> -----------
> - https://bugzilla.redhat.com/show_bug.cgi?id=1188219
> - https://mail.gnome.org/archives/gtk-perl-list/2015-January/msg00039.html
> - https://bugs.mageia.org/show_bug.cgi?id=15173
> - https://lwn.net/Vulnerabilities/633094/
In this situation, we didn't immediately reach a conclusion about how
to incorporate the perspective of the upstream vendor. Specifically,
https://mail.gnome.org/archives/gtk-perl-list/2015-January/msg00042.html
says 'Do you really need such an "official" and elaborate effort for
this kind of bug fix? These kinds of fixes are done all over the place
all the time without special announcements.'
The upstream fix removes a "g_list_free (devices);" with a comment of
"Fix incorrect memory management in
Gtk2::Gdk::Display::list_devices ... We do not own the returned list."
https://bugs.mageia.org/show_bug.cgi?id=15173#c3 says "Did not find
any PoC."
Maybe the initial question is "do all changes of this type, in all
products, always qualify for a CVE ID?"
If, for example, the upstream vendor meant that "all over the place
all the time" fixes are exclusively "fixes for issues that are known
to be non-exploitable, not even for a crash," then we think there
probably should not be a CVE ID. If nobody has any definitive
information about an impact, then the answer is much less clear.
Before assigning a CVE ID, we might (or might not) want to require
further information, such as how is "devices" used after the
g_list_free. A recent academic paper that tries to further categorize
related issues is:
http://www.cc.gatech.edu/~blee303/paper/dangnull.pdf
The timeline seems to be:
1. An incorrect g_list_free was found. There's perhaps no information
about how it was found. It might, for example, have been found
through an automated testing approach that has the potential of
discovering thousands of similar code problems.
2. The fix was mentioned in an upstream announcement of a new release.
3. One or more persons in the Linux vendor community noticed the new
release (possibly because of automated checking for new upstream
releases).
4. Because the type of code problem is one that is sometimes (one may
argue "frequently") exploitable, multiple Linux vendors distributed
a fix.
5. There doesn't seem to be a reference indicating that any analysis
of impact was done, or that otherwise tries to establish that this
specific code issue is best categorized as a vulnerability.
6. Still, there is interest in a CVE ID because Linux vendors often
have a CVE mapping associated with a code change of this type.
It's unclear to us exactly what should happen here. Should we be using
a "per release" attribute as one aspect of deciding whether a CVE ID
is needed? (Specifically, because this one code change was apparently
the primary motivation for releasing 1.2495, does that increase the
importance of having a CVE ID?) Is it sufficient that everybody agrees
the code was wrong and that nobody has ruled out exploitability? If
someone happens to enumerate the complete set of the "all over the
place all the time" fixes that the upstream vendor mentioned, do they
all need CVE IDs as well?
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVAdeZAAoJEKllVAevmvmsjyQIAKlLxx+HppJjgtlQSYIIpugq
rq+2HnNFsdMBzA6THF33tX8gUxXH7B3q7inZxdVFmGeqX0mYfw6pjZD77gYXFXP1
dpra/sVxZF5HoQBFdoYDxbNn2RA2pNwSe4oxc9z3NivCQwEcpRYdUHVeLtBKCqrN
kEjagGcb7rlDC/2uegNlbRdqbXbWUYfXQf4EW4GTci6jvzzifFw38IYLyQ+UO00S
LtHd5kZfdJ5PZiC+PITsNYcjM3am41mJwggrHChOwzhN0+Dx1LsH0kUlrTBlCZBE
vX8SHiIwZK0xoiF2lbPTZYhctWNbf8hS03/k0uCIgRbUbhBQ2xc92DwXj9S9jls=
=uC8N
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
