[Secure-testing-team] Re: summary of what's blocking security fixes

[Javier Fernández-Sanguino Peña]

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