Secure testing team - Mar 2006 - [patch 0/3] Syntax tweaks for data/CAN/list

The following patches correct syntax anomalies in the data/CAN/list
file.  These were uncovered by processing the file with a more
restrictive parser.

The patches for HELP and DONE replace these tags with the TODO tag.  Do
not apply them if you want to keep these tags, but I''d prefer them to
go away.

Index: secure-testing/data/CAN/list
==================================================================---
secure-testing.orig/data/CAN/list	2005-09-10 16:28:02.000000000 +0200
+++ secure-testing/data/CAN/list	2005-09-10 16:31:21.000000000 +0200
@@ -1611,7 +1611,7 @@
 CAN-2005-2404 (SQL injection vulnerability in sendcard.php in Sendcard 3.2.3
allows ...)
 	NOTE: not-for-us (Sendcard)
 CAN-2005-2403 (The login protocol in RealChat 3.5.1b does not use
authentication, ...)
-	NPTE: not-for-us (RealChat)
+	NOTE: not-for-us (RealChat)
 CAN-2005-2402 (Cross-site scripting (XSS) vulnerability in search.php in ...)
 	NOTE: not-for-us (PHPSiteSearch)
 CAN-2005-2401 (PHP-Fusion allows remote attackers to inject arbitrary Cascading
Style ...)
@@ -2152,7 +2152,7 @@
 CAN-2002-2060 (Buffer overflow in Links 2.0 pre4 allows remote attackers to
crash ...)
 	- links2 2.1pre16-2 (low)
 CAN-2002-2059 (BIOS D845BG, D845HV, D845PT and D845WN on Intel motherboards
does not ...)
-	NOTE; not-for-us (Intel)
+	NOTE: not-for-us (Intel)
 CAN-2002-2058 (TeeKai Tracking Online 1.0 uses weak encryption of web usage
...)
 	NOTE: not-for-us (TeeKai)
 CAN-2002-2057 (TeeKai Forum 1.2 uses weak encryption of web usage statistics in
...)
@@ -4439,7 +4439,7 @@
 	- kernel-source-2.4.27 2.4.27-11 (medium)
 CAN-2005-1767 (Unknown vulnerability in the Linux kernel 2.6.x and 2.4.x allows
local ...)
 	NOTE: linux-2.6 not affected (already fixed)
-	- kernel-source 2.4.27 2.4.27-11 (unknown)
+	- kernel-source-2.4.27 2.4.27-11 (unknown)
 CAN-2005-1766 (Heap-based buffer overflow in rtffplin.cpp in RealPlayer 10.5
...)
 	NOTE: not-for-us (RealPlayer)
 CAN-2005-1765 (syscall in the Linux kernel 2.6.8.1 and 2.6.10 for the AMD64
platform, ...)
@@ -6019,7 +6019,7 @@
 	NOTE: not-for-us (Apple)
 CAN-2005-1471 (Heap-based buffer overflow in RSA SecurID Web Agent 5, 5.2, and
5.3 ...)
 	NOTE: not-for-us (RSA SecurID Web Agent)
-CAn-2005-XXXX [race condition with a buffered temp file]
+CAN-2005-XXXX [race condition with a buffered temp file]
 	NOTE: no bug ever filed for this one
 	- pysvn 1.1.2-3
 CAN-2005-XXXX [mailutils: sql injection vulnerability in sql authentication
module]
@@ -12371,7 +12371,7 @@
 	NOTE: not-for-us (BEA WebLogic Server and WebLogic Express)
 CAN-2004-0651 (Unknown vulnerability in Sun Java Runtime Environment (JRE)
1.4.2 ...)
 	NOTE: JRE is not in Debian, assuming the various wrappers handle
-	NOTE the new version. Not worrying about upgrades.
+	NOTE: the new version. Not worrying about upgrades.
 CAN-2004-0650 (UploadServlet in Cisco Collaboration Server (CCS) running
ServletExec ...)
 	NOTE: not-for-us (Cisco)
 CAN-2004-0649 (Buffer overflow in write_packet in control.c for l2tpd may allow
...)
@@ -14739,7 +14739,7 @@
 CAN-2003-0512 (Cisco IOS 12.2 and earlier generates a "% Login
invalid" message ...)
 	NOTE: not-for-us (Cisco)
 CAN-2003-0511 (The web server for Cisco Aironet AP1x00 Series Wireless devices
...)
-	NOTE not-for-us (Cisco Aironet AP1x00 Series Wireless devices)
+	NOTE: not-for-us (Cisco Aironet AP1x00 Series Wireless devices)
 CAN-2003-0510 (Format string vulnerability in ezbounce 1.0 through 1.50 allows
remote ...)
 	NOTE: not-for-us (ezbounce)
 CAN-2003-0509 (SQL injection vulnerability in Cyberstrong eShop 4.2 and earlier
...)

--

* Neil McGovern:
> On Sat, Sep 10, 2005 at 04:46:28PM +0200, Florian Weimer wrote:
>> The following patches correct syntax anomalies in the data/CAN/list
>> file.  These were uncovered by processing the file with a more
>> restrictive parser.
>> 
>
> Thanks, I''ve applied these :)
Thanks, that was fast.  Now I have to figure out how to tell quilt
that my local patch is obsolete. 8-/
> Neil
> ps: not sure if you''re subscribed, so I cc:ed you. Apologies if
you are.
I''m subscribed, but I nevertheless prefer Cc:s.

Micah Anderson wrote:
> Now that the list is getting cleaned up, we need to work on ways to keep it
> from getting messy again, an emacs minor mode would be nice,
Won''t fit the vim folks, but they''re trouble-makers anyway ;-)
> Additionally, as we get more people helping, I think improving our
> documentation would also help significantly for people getting up to speed
> (except in the case of typos, or synaptic misfires of course). It might be
> good to brainstorm at Oldenburg some other things that should be
documented,
> I can think of a couple things off the top of my head: what ways do
> you check to see if a vulnerability affects debian?; the IRC channel;
> workflow (claiming, filing bugs, working with package maintainers, etc.)
> handling kernel issues; embedded source issues; severity levels; obtaining
> CVE identifiers; mailing lists to monitor; websites to
frequent/aggragate...
> I am sure there are many more.
As already said on IRC, I''d really like to have an "agenda",
this makes things
a lot more productive. I already have a lengthy list of issues I''d like
to have
discussed/implemented, but need some time to clean it up/rethink it.
So please, could anyone write up a list of things he''d like to have
discussed/
worked on? Either post them to the list or send them to me and I''ll
compile
a list. We should schedule an IRC meeting with Martin Pitt during Oldenburg,
I''d
really like to involve Ubuntu as well.

Thanks,
        Moritz

Moritz Muehlenhoff schrieb am Sunday, den 11. September 2005:
> Florian Weimer wrote:
> > > Florian Weimer wrote:
> > >> The following patches correct syntax anomalies in the
data/CAN/list
> > >> file.  These were uncovered by processing the file with a
more
> > >> restrictive parser.
> > >
> If you want to improve the syntactical quality of the entries in a
"proactive"
> manner, please contribute a comfortable Emacs minor mode :-)
Now that the list is getting cleaned up, we need to work on ways to keep it
from getting messy again, an emacs minor mode would be nice, but maybe the
restrictive parser can act as our sort of lintian to run over the list
before submission.

Additionally, as we get more people helping, I think improving our
documentation would also help significantly for people getting up to speed
(except in the case of typos, or synaptic misfires of course). It might be
good to brainstorm at Oldenburg some other things that should be documented,
I can think of a couple things off the top of my head: what ways do
you check to see if a vulnerability affects debian?; the IRC channel;
workflow (claiming, filing bugs, working with package maintainers, etc.)
handling kernel issues; embedded source issues; severity levels; obtaining
CVE identifiers; mailing lists to monitor; websites to frequent/aggragate...
I am sure there are many more.

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050911/522d125e/attachment.pgp

On Mon, Sep 12, 2005 at 12:18:45AM +0200, Moritz Muehlenhoff
wrote:
> Micah Anderson wrote:
> > Now that the list is getting cleaned up, we need to work on ways to
keep it
> > from getting messy again, an emacs minor mode would be nice,
> 
> Won''t fit the vim folks, but they''re trouble-makers
anyway ;-)
> 
That we are :)

Mind you, emacs isn''t even installed on my boxes. Somethign a little
more independant would be better.

Neil
-- 
   __   
 .?  `. neilm@debian.org | Application Manager
 : :'' ! ---------------- | Secure-Testing Team member
 `. `?  gpg: B345BDD3    | Webapps Team member
   `-   Please don''t cc, I''m subscribed to the list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050912/f2bcb6f4/attachment.pgp

Florian Weimer wrote:
> There''s a piece of syntax I don''t understand. 
What''s the difference
> between
> 
>         - mysql-dfsg 4.0.18-4
> 
> and
> 
>         ! mysql-dfsg 4.0.18-6
> 
> ?  Is the "!" of any special significance?
It''s a typo, fix commited a minute ago.

Cheers,
        Moritz

On Sat, Sep 10, 2005 at 04:46:28PM +0200, Florian Weimer
wrote:
> The following patches correct syntax anomalies in the data/CAN/list
> file.  These were uncovered by processing the file with a more
> restrictive parser.
> 
Thanks, I''ve applied these :)

Neil
ps: not sure if you''re subscribed, so I cc:ed you. Apologies if you
are.
-- 
   __   
 .´  `. neilm@debian.org | Application Manager
 : :'' ! ---------------- | Secure-Testing Team member
 `. `´  gpg: B345BDD3    | Webapps Team member
   `-   Please don''t cc, I''m subscribed to the list

Index: secure-testing/data/CAN/list
==================================================================---
secure-testing.orig/data/CAN/list	2005-09-10 16:33:36.000000000 +0200
+++ secure-testing/data/CAN/list	2005-09-10 16:34:50.000000000 +0200
@@ -11933,7 +11933,7 @@
 	- star 1.5a46
 CAN-2004-0849 (Integer overflow in the asn_decode_string() function defined in
asn1.c ...)
 	NOTE: not vulnerable according to
http://www.debian.org/security/nonvulns-sarge
-	HELP: which radius daemon in debian is "GNU Radius" (if any)?
+	TODO: which radius daemon in debian is "GNU Radius" (if any)?
 CAN-2004-0848 (Buffer overflow in Microsoft Office XP allows remote attackers
to ...)
 	NOTE: not-for-us (microsoft)
 CAN-2004-0847 (The Microsoft .NET forms authentication capability for ASP.NET
allows ...)

--

* Moritz Muehlenhoff:
> Florian Weimer wrote:
>> The following patches correct syntax anomalies in the data/CAN/list
>> file.  These were uncovered by processing the file with a more
>> restrictive parser.
>
> These look good. Is this parser publicly available?
Probably after this weekend.  It will be a Python module--hope you
don''t mind.
>> The patches for HELP and DONE replace these tags with the TODO tag.  Do
>> not apply them if you want to keep these tags, but I''d prefer
them to
>> go away.
>
> HELP looks fine, but DONE is not useful:
> If a checked vulnerability turned out to be a vulnerability it is tracked
as
> - foo x.y-z (bug #gamma; medium)
> if it''s not affected it is tracked as
> - foo not-affected (bug #gamma; medium)
I fail to see how your comment applies to my patch. 8-)

Index: secure-testing/data/CAN/list
==================================================================---
secure-testing.orig/data/CAN/list	2005-09-10 16:34:50.000000000 +0200
+++ secure-testing/data/CAN/list	2005-09-10 16:35:25.000000000 +0200
@@ -4565,8 +4565,8 @@
 CAN-2004-2098 (Cross-site scripting (XSS) vulnerability in the banner engine
(TBE) ...)
 	NOTE: not-for-us (Banner engine)
 CAN-2004-2097 (Multiple scripts on SuSE Linux 9.0 allow local users to
overwrite ...)
-	DONE: check these packages, whether they create tempfiles with the current
PID:
-	DONE: fvwm, fvwm-gnome, x-base-clients, lvm10
+	TODO: check these packages, whether they create tempfiles with the current
PID:
+	NOTE: DONE: fvwm, fvwm-gnome, x-base-clients, lvm10
 	NOTE: fvwm: uses mktemp
 	NOTE: fvwm-gnome: same as fvwm
 	NOTE: x-base-clients: x11perfcomp uses mkdir atomically

--

Florian Weimer wrote:
> The following patches correct syntax anomalies in the data/CAN/list
> file.  These were uncovered by processing the file with a more
> restrictive parser.
These look good. Is this parser publicly available?
 
> The patches for HELP and DONE replace these tags with the TODO tag.  Do
> not apply them if you want to keep these tags, but I''d prefer them
to
> go away.
HELP looks fine, but DONE is not useful:
If a checked vulnerability turned out to be a vulnerability it is tracked as 
- foo x.y-z (bug #gamma; medium)
if it''s not affected it is tracked as
- foo not-affected (bug #gamma; medium)

Cheers,
        Moritz

Florian Weimer wrote:
> > Florian Weimer wrote:
> >> The following patches correct syntax anomalies in the
data/CAN/list
> >> file.  These were uncovered by processing the file with a more
> >> restrictive parser.
> >
> > These look good. Is this parser publicly available?
> 
> Probably after this weekend.  It will be a Python module--hope you
> don''t mind.
Python is the preferred language, at least for me.

If you want to improve the syntactical quality of the entries in a
"proactive"
manner, please contribute a comfortable Emacs minor mode :-)
 
> >> The patches for HELP and DONE replace these tags with the TODO
tag.  Do
> >> not apply them if you want to keep these tags, but I''d
prefer them to
> >> go away.
> >
> > HELP looks fine, but DONE is not useful:
> > If a checked vulnerability turned out to be a vulnerability it is
tracked as
> > - foo x.y-z (bug #gamma; medium)
> > if it''s not affected it is tracked as
> > - foo not-affected (bug #gamma; medium)
> 
> I fail to see how your comment applies to my patch. 8-)
Nevermind, I misread this. I thought I wanted to introduce "DONE:".

Cheers,
        Moritz

* Micah Anderson:
> Now that the list is getting cleaned up, we need to work on ways to keep it
> from getting messy again, an emacs minor mode would be nice,
I doubt that all these little issues can be checked in an Emacs mode.
Not everything is a regular expression, and the cross-database checks
are totally out of question.
> but maybe the restrictive parser can act as our sort of lintian to
> run over the list before submission.
It''s also possible to run the parser on costa, before the check-in is
approved.  But this might be too drastic.
> Additionally, as we get more people helping, I think improving our
> documentation would also help significantly for people getting up to speed
> (except in the case of typos, or synaptic misfires of course).
For the list files, I plan to add a free-form header which is skipped
by the parser, so that we can explain the syntax in the file.

There''s a piece of syntax I don''t understand.  What''s
the difference
between

        - mysql-dfsg 4.0.18-4

and

        ! mysql-dfsg 4.0.18-6

?  Is the "!" of any special significance?

* Moritz Muehlenhoff:
> Florian Weimer wrote:
>> There''s a piece of syntax I don''t understand. 
What''s the difference
>> between
>> 
>>         - mysql-dfsg 4.0.18-4
>> 
>> and
>> 
>>         ! mysql-dfsg 4.0.18-6
>> 
>> ?  Is the "!" of any special significance?
>
> It''s a typo, fix commited a minute ago.
But bin/checklist checks explicitly for it:

   elsif (/^\s+[!-]\s+(\S+)\s+(.*?)\s*$/) { # Deal with ...

Somehow I doubt that this is a mere typo.  Of course, I can replace
all the "!"  entries with "-" if this syntax is just a minor
variant.
For now, I just ignore the difference.

And it''s also a bit strange that DSA/list and DTSA/list use different
date formats. 8-)

* Moritz Muehlenhoff:
> It was historically used for denoting, whether an issue was fixed in
> testing. They should all be converted to "-".
Good.  I''m going to enforce this in "make check", and clean
up the
remaining occurrences.

Florian Weimer wrote:
> >> There''s a piece of syntax I don''t understand. 
What''s the difference
> >> between
> >> 
> >>         - mysql-dfsg 4.0.18-4
> >> 
> >> and
> >> 
> >>         ! mysql-dfsg 4.0.18-6
> >> 
> >> ?  Is the "!" of any special significance?
> >
> > It''s a typo, fix commited a minute ago.
> 
> But bin/checklist checks explicitly for it:
> 
>    elsif (/^\s+[!-]\s+(\S+)\s+(.*?)\s*$/) { # Deal with ...
> 
> Somehow I doubt that this is a mere typo.  Of course, I can replace
> all the "!"  entries with "-" if this syntax is just a
minor variant.
> For now, I just ignore the difference.
It was historically used for denoting, whether an issue was fixed in
testing. They should all be converted to "-".

Cheers,
        Moritz