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/
signature.asc
Description: Digital signature
