Secure testing team - Mar 2006 - Re: summary of what''s blocking security fixes

On Wed, Sep 14, 2005 at 12:02:29AM -0400, Nathanael Nerode
wrote:
> 
> >lm-sensors
> >        23 days old
> >        indirectly blocked by perl
> Hmm.  No idea how long perl will take, so this probably deserves an upload
> if the vulnerability is serious enough.
The vulnerability is not serious enough to merit an upload to testing. After
all it''s a local-only vulnerability which only triggers when the
program is
run (and no cron task or daemon runs it automatically) so the window of
exposure is rather small. The program, whoever, is run as root, so the risk
in that window is high.

Based on this, the CVSS [1] base score is 3,8, which is probably lower than
some other vulnerabilities out there. Why not standarize in a given metric to
score vulnerabilites so that the work can be priorised? 

This is usually done in an informal way:

- "Fix remote holes first then local holes (that require an authenticated
  user)"
- "Fix holes in most deployed software then on software that is rarely
  installed or used"
- "Fix holes that can be targeted in a programatic way (i.e. cron job,
  daemon) before holes that require user intervention"

IMHO the information used by the Security testing teams (both for testing and
stable) should use metrics like CVSS to formalize the above. 

Just wanted to throw the idea in case somebody wants to go ahead and
implement it :-)

Regards

Javier


[1] http://www.first.org/cvss/ and
http://www.packetfactory.net/papers/CVSS/
-------------- 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/20050914/fafb0e14/attachment.pgp

On Wed, Sep 14, 2005 at 12:02:29AM -0400, Nathanael Nerode
wrote:
> To quote Steve Langasek:
> # waits for efax-gtk,timfx to be build on m68k,
> # gnomoradio,libgdamm1.3,libpanelappletmm2.6,lostirc,quickplot transitioned
> Bugs have been filed against the packages needing transitioned uploads.
> NMUs are a good idea too.
Yes, NMUs are a very good idea.  There are a few more packages than
that, because libgc is linked to this transition.  yehia, stalin,
w3mmee, and oo2c seem to be the others, and I''m working through this
list now with NMUs.
> >ntp
> >        177 days old
> >        3 RC bugs, max 98 days old, none with responses from
maintainers
> >        recommend removal from testing (and/or debian)
> Good grief.  And it''s team-maintained, too.
> CC:ing all maintainers.
  ^^^^^^^^^^^^^^^^^^^^^^^

Not AFAICT?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
-------------- 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/20050914/612163dd/attachment.pgp

Joey Hess wrote:
>RM summary: m68k is killing us with ICE after ICE and contributing to
>blocking hald of the fixes. The transitions arn''t hurting as much
after
>the last heroic britney run, although kde/qt is of course a problem.
Time to declare m68k broken.
>Testing team summary: well, of these asterisk, inkscape, some kde stuff,
>lm-sensors, mysql-dfsg-4.1, and texmacs seem like the most likely
>candidates for upload to secure-testing, although some of the holes may
>not warrant a DTSA.
>
>asterisk
>        30 days old
>        blocked indirectly by qt transition
Deserves a secure-testing upload.
>inkscape
>        20 days old
>        blocked by libsigc++-2.0
To quote Steve Langasek:
# waits for efax-gtk,timfx to be build on m68k,
# gnomoradio,libgdamm1.3,libpanelappletmm2.6,lostirc,quickplot transitioned
Bugs have been filed against the packages needing transitioned uploads.
NMUs are a good idea too.
This cluster could go in in a week or less, so it may not be worth a security
upload.
>lm-sensors
>        23 days old
>        indirectly blocked by perl
Hmm.  No idea how long perl will take, so this probably deserves an upload
if the vulnerability is serious enough.
>mozilla (partially fixed in secure-testing)
>        41 days old, AKA, is this package being maintained?
Clearly not.
>        rc bugs, FTBDS, etc
>ntp
>        177 days old
>        3 RC bugs, max 98 days old, none with responses from maintainers
>        recommend removal from testing (and/or debian)
Good grief.  And it''s team-maintained, too.
CC:ing all maintainers.

I''d hate to see this drop out of Debian.  Shall I prepare an NMU?
>openmotif
>        106 days old
>        non-free package, still missing s390 build
>        (I tried and failed to build this on raptor, machine is too
>        unstable.)
Drop from testing?

-- 
Nathanael Nerode  <neroden@twcny.rr.com>

This space intentionally left blank.

[Trimming out -release]

Javier Fern?ndez-Sanguino Pe?a wrote:
> Based on this, the CVSS [1] base score is 3,8, which is probably lower than
> some other vulnerabilities out there. Why not standarize in a given metric
to
> score vulnerabilites so that the work can be priorised? 
> 
> This is usually done in an informal way:
>
> IMHO the information used by the Security testing teams (both for testing
and
> stable) should use metrics like CVSS to formalize the above. 
The testing security already uses an informal pattern (low, medium and high),
bit it''s only used for internal priorization. It can be seen through
the
coloring on spohr.debian.org/~joeyh/testing-security.html, though.

Metrics like CVSS with post-comma precision values feign an precision that
can''t really withstand reality, as there are too many local factors to
consider
a site-specific graveness of a vulnerability.

Cheers,
        Moritz