[Secure-testing-team] [Secure-testing-commits] r12708 - data/CVE

[Michael S Gilbert]

On Mon, 31 Aug 2009 03:09:02 +0200 Nico Golde wrote:

> Hi,
> * Michael S Gilbert <michael.s.gilbert at gmail.com> [2009-08-31 02:29]:
> > On Mon, 31 Aug 2009 00:23:00 +0200 Nico Golde wrote:
> > 
> > > * Michael Gilbert <gilbert-guest at alioth.debian.org> [2009-08-30 19:06]:
> > > > Author: gilbert-guest
> > > > Date: 2009-08-30 17:09:16 +0000 (Sun, 30 Aug 2009)
> > > > New Revision: 12708
> > > > 
> > > > Modified:
> > > >    data/CVE/list
> > > > Log:
> > > > beginning of embedded code copies triage (5 down 395 to go)
> > > > 
> > > > Modified: data/CVE/list
> > > > ===================================================================
> > > > --- data/CVE/list	2009-08-30 03:00:07 UTC (rev 12707)
> > > > +++ data/CVE/list	2009-08-30 17:09:16 UTC (rev 12708)
> > > > @@ -1286,6 +1286,7 @@
> > > >  CVE-2009-2660 (Multiple integer overflows in CamlImages 2.2 might allow ...)
> > > >  	{DSA-1857-1}
> > > >  	- camlimages 1:3.0.1-3 (medium; bug #540146)
> > > > +	- advi <not-affected> (affected code section not present in advi code copy of camlimages)
> > > >  CVE-2009-2657 (nilfs-utils before 2.0.14 installs multiple programs with unnecessary ...)
> > > >  	- nilfs2-tools <not-affected> (dh_fixperms removes the setuid and setgid bits from all files)
> > > >  CVE-2009-2656 (Unspecified vulnerability in the com.android.phone process in Android ...)
> > > > @@ -1303,6 +1304,8 @@
> > > >  CVE-2009-XXXX [VLC: integer underflow in Real RTSP]
> > > >  	- vlc 1.0.1-1
> > > >  	- mplayer <unfixed>
> > > > +	- xine-lib <unfixed>
> > > > +        NOTE: affected mplayer code copy present in xine-lib
> > > 
> > > Did you only check if the code is present or also if it's 
> > > used?
> > 
> > yes, i only checked that the embedded code is present.  after further
> > review of the full disclosure posting, it is clear that xine-lib is not
> > affected because it has additional an additional check.
> 
> I wasn't talking about this issue in specific, just noticed 
> it in this commit. If you didn't do that yet please do so to 
> avoid lots of false-positives and someone needs to do the 
> work anyway.

if the affected code is present, isn't it almost always the case that
it is actually used?  the only situation where this isn't the case (that
i can think of right now) is dead code, which the maintainer should
probably be working with upstream to remove anyway.

would it be ok for me to add a 'TODO: <x> code copy present, check
whether it is used' when i find that the code copy is in the package?
figuring out whether the affected code is present in these 400
instances is already quite an undertaking, and it will be significantly
more work to parse all the make files to determine if that code gets
built and gets called from somewhere.  i would hope others may be
willing/able to help out at that point?

mike