Secure testing commits - Aug 2009 - r12531 - data/CVE

Author: nion
Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
New Revision: 12531

Modified:
   data/CVE/list
Log:
add todos for new items, please do that as well next time

Modified: data/CVE/list
==================================================================---
data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
+++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
@@ -4,11 +4,13 @@
 	- rubygems <not-affected>
 	NOTE: debian''s version installs gems packages to /var/lib/gems,
 	NOTE: so no opportunity to overwrite system files
+	TODO: request CVE id
 CVE-2009-XXXX [bugzilla: unauthorized bug modification]
 	- bugzilla 3.2.4-1 (low)
 	[etch] - bugzilla <no-dsa> (minor issue)
 	[lenny] - bugzilla <no-dsa> (minor issue)
 	NOTE: https://bugzilla.mozilla.org/show_bug.cgi?id=495257
+	TODO: request CVE id
 CVE-2009-XXXX [groff: insecure usage of gs]
 	- groff <unfixed> (low; bug #538338)
 	[etch] - groff <no-dsa> (minor issue)
@@ -22,12 +24,15 @@
 CVE-2009-XXXX [netbase: wireless key logged]
 	- netbase <unfixed> (low; bug #540608)
 	TODO: follow-up with maintainer to find out if debian''s version is
affected or not
+	TODO: request CVE id
 CVE-2009-XXXX [apache2: only first 8 characters used to validate password]
 	- apache2 <unfixed> (low; bug #539246)
 CVE-2009-XXXX [gnudips: remote priviledge escalation]
 	- gnudips <unfixed> (medium; bug #539452)
+	TODO: request CVE id
 CVE-2009-XXXX [xscreensaver: local screen lock bypassable via low resolution
video devices]
 	- xscreensaver <unfixed> (low; bug #539699)
+	TODO: request CVE id
 CVE-2009-XXXX [php5: remote information disclosure]
 	- php5 <unfixed> (medium; bug #540605)
 	TODO: determine affected versions
@@ -45,6 +50,7 @@
 CVE-2009-XXXX [linux-2.6: md raid null pointer dereference (when sysfs
available)]
 	- linux-2.6 <unfixed> (medium)
 	- linux-2.6.24 <removed>
+	NOTE: CVE id requested on oss-sec
 CVE-2009-2710
 	RESERVED
 CVE-2009-2709

On Sun,  9 Aug 2009 13:56:23 +0000 Nico Golde wrote:
> Author: nion
> Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
> New Revision: 12531
> 
> Modified:
>    data/CVE/list
> Log:
> add todos for new items, please do that as well next time
> 
> Modified: data/CVE/list
> ==================================================================> ---
data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
> +++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
> @@ -4,11 +4,13 @@
>  	- rubygems <not-affected>
>  	NOTE: debian''s version installs gems packages to /var/lib/gems,
>  	NOTE: so no opportunity to overwrite system files
> +	TODO: request CVE id
ok, is a mail to oss-sec like yours sufficient?  also, i thought there
were going to be some workflow changes where the security team could
autonomously assign a CVE from a pool allocated to debian.  are there
any formal plans for that?  or would that only be done along with a DSA?

mike

Hi,
* Michael S. Gilbert <michael.s.gilbert at gmail.com> [2009-08-09
18:42]:
> On Sun,  9 Aug 2009 13:56:23 +0000 Nico Golde wrote:
> 
> > Author: nion
> > Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
> > New Revision: 12531
> > 
> > Modified:
> >    data/CVE/list
> > Log:
> > add todos for new items, please do that as well next time
> > 
> > Modified: data/CVE/list
> > ==================================================================>
> --- data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
> > +++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
> > @@ -4,11 +4,13 @@
> >  	- rubygems <not-affected>
> >  	NOTE: debian''s version installs gems packages to
/var/lib/gems,
> >  	NOTE: so no opportunity to overwrite system files
> > +	TODO: request CVE id
> 
> ok, is a mail to oss-sec like yours sufficient?  also, i thought there
> were going to be some workflow changes where the security team could
> autonomously assign a CVE from a pool allocated to debian.  are there
> any formal plans for that?  or would that only be done along with a DSA?
Sorry misunderstanding, I was just referring to the TODO 
entries. Just add those TODOs in the future and you''ll be 
fine. Just want to make sure nothing is missing later.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090809/b0cb6700/attachment.pgp>

On Sun, 9 Aug 2009 19:02:49 +0200 Nico Golde wrote:
> Hi,
> * Michael S. Gilbert <michael.s.gilbert at gmail.com> [2009-08-09
18:42]:
> > On Sun,  9 Aug 2009 13:56:23 +0000 Nico Golde wrote:
> > 
> > > Author: nion
> > > Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
> > > New Revision: 12531
> > > 
> > > Modified:
> > >    data/CVE/list
> > > Log:
> > > add todos for new items, please do that as well next time
> > > 
> > > Modified: data/CVE/list
> > >
==================================================================> > >
--- data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
> > > +++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
> > > @@ -4,11 +4,13 @@
> > >  	- rubygems <not-affected>
> > >  	NOTE: debian''s version installs gems packages to
/var/lib/gems,
> > >  	NOTE: so no opportunity to overwrite system files
> > > +	TODO: request CVE id
> > 
> > ok, is a mail to oss-sec like yours sufficient?  also, i thought there
> > were going to be some workflow changes where the security team could
> > autonomously assign a CVE from a pool allocated to debian.  are there
> > any formal plans for that?  or would that only be done along with a
DSA?
> 
> Sorry misunderstanding, I was just referring to the TODO 
> entries. Just add those TODOs in the future and you''ll be 
> fine. Just want to make sure nothing is missing later.
ok, can and should i go ahead and send the mail to oss-sec also?  or are
only select people in debian supposed to do that?

mike

On Sun, Aug 09, 2009 at 01:34:21PM -0400, Michael S. Gilbert
wrote:
> On Sun, 9 Aug 2009 19:02:49 +0200 Nico Golde wrote:
> 
> > Hi,
> > * Michael S. Gilbert <michael.s.gilbert at gmail.com>
[2009-08-09 18:42]:
> > > On Sun,  9 Aug 2009 13:56:23 +0000 Nico Golde wrote:
> > > 
> > > > Author: nion
> > > > Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
> > > > New Revision: 12531
> > > > 
> > > > Modified:
> > > >    data/CVE/list
> > > > Log:
> > > > add todos for new items, please do that as well next time
> > > > 
> > > > Modified: data/CVE/list
> > > >
==================================================================> > >
> --- data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
> > > > +++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
> > > > @@ -4,11 +4,13 @@
> > > >  	- rubygems <not-affected>
> > > >  	NOTE: debian''s version installs gems packages to
/var/lib/gems,
> > > >  	NOTE: so no opportunity to overwrite system files
> > > > +	TODO: request CVE id
> > > 
> > > ok, is a mail to oss-sec like yours sufficient?  also, i thought
there
> > > were going to be some workflow changes where the security team
could
> > > autonomously assign a CVE from a pool allocated to debian.  are
there
> > > any formal plans for that?  or would that only be done along with
a DSA?
> > 
> > Sorry misunderstanding, I was just referring to the TODO 
> > entries. Just add those TODOs in the future and you''ll be 
> > fine. Just want to make sure nothing is missing later.
> 
> ok, can and should i go ahead and send the mail to oss-sec also?  or are
> only select people in debian supposed to do that?
We should be careful that IDs are only requested if they''ve received
a little bit of investigation to prevent bogus issues from receiving
a CVE ID. I guess it depends on where the information is coming from.

Cheers,
        Moritz

On Sun, 9 Aug 2009 21:11:44 +0200 Moritz Muehlenhoff wrote:
> On Sun, Aug 09, 2009 at 01:34:21PM -0400, Michael S. Gilbert wrote:
> > On Sun, 9 Aug 2009 19:02:49 +0200 Nico Golde wrote:
> > 
> > > Hi,
> > > * Michael S. Gilbert <michael.s.gilbert at gmail.com>
[2009-08-09 18:42]:
> > > > On Sun,  9 Aug 2009 13:56:23 +0000 Nico Golde wrote:
> > > > 
> > > > > Author: nion
> > > > > Date: 2009-08-09 13:56:23 +0000 (Sun, 09 Aug 2009)
> > > > > New Revision: 12531
> > > > > 
> > > > > Modified:
> > > > >    data/CVE/list
> > > > > Log:
> > > > > add todos for new items, please do that as well next
time
> > > > > 
> > > > > Modified: data/CVE/list
> > > > >
==================================================================> > >
> > --- data/CVE/list	2009-08-09 13:55:11 UTC (rev 12530)
> > > > > +++ data/CVE/list	2009-08-09 13:56:23 UTC (rev 12531)
> > > > > @@ -4,11 +4,13 @@
> > > > >  	- rubygems <not-affected>
> > > > >  	NOTE: debian''s version installs gems
packages to /var/lib/gems,
> > > > >  	NOTE: so no opportunity to overwrite system files
> > > > > +	TODO: request CVE id
> > > > 
> > > > ok, is a mail to oss-sec like yours sufficient?  also, i
thought there
> > > > were going to be some workflow changes where the security
team could
> > > > autonomously assign a CVE from a pool allocated to debian. 
are there
> > > > any formal plans for that?  or would that only be done along
with a DSA?
> > > 
> > > Sorry misunderstanding, I was just referring to the TODO 
> > > entries. Just add those TODOs in the future and you''ll
be
> > > fine. Just want to make sure nothing is missing later.
> > 
> > ok, can and should i go ahead and send the mail to oss-sec also?  or
are
> > only select people in debian supposed to do that?
> 
> We should be careful that IDs are only requested if they''ve
received
> a little bit of investigation to prevent bogus issues from receiving
> a CVE ID. 
i understand the need for care, and i am being careful, but i don''t see
this as much of a problem.  if an issue is subsequently determined to be
unimportant, it can just get REJECTED. i''d rather err on the side of
caution and get a CVE for all potential security issues so they can be
uniquely and globally tracked (and not just within debian).

but i will follow your guidelines.  if you just want TODOs, then i will
just do TODOs.
> I guess it depends on where the information is coming from.
the sources of the problems i have been reporting are either
oss-security, fulldisclosure, or other distro security mailing list.

mike

On Sun, Aug 09, 2009 at 11:12:48PM -0400, Michael S. Gilbert
wrote:
> > I guess it depends on where the information is coming from.
> 
> the sources of the problems i have been reporting are either
> oss-security, fulldisclosure, or other distro security mailing list.
Anything from oss-security is picked up by MITRE anyway, so no need
for a separate request. For issues posted to full-disclosure, a
request on oss-security is a good idea and likewise for vendor
advisories (although most should have CVE IDs already).

Cheers,
        Moritz