On Sat, Dec 18, 2004 at 02:02:35PM +0100, Ulf Härnhammar wrote:
> Quoting Javier Fernández-Sanguino Peña <jfs_at_debian.org>:
>
> > I was wondering if anyone had done an analysis of the published
> > DSAs based on;
> >
> > - package priority (i.e. 'base', 'standard', etc.)
> > - type of security flaw (buffer overflow, logical error, integer overflow,
> > etc.)
> > - type of impact (denial of service, authentication, remote code execution,
> > privilege escalation, etc.)
> > - risk (that is, how "dangerous" is the vulnerability to common users)
>
> Secunia ( http://secunia.com/ ) does some of that, and they cover all
> vulnerabilities. US-CERT ( http://www.uscert.gov/ ) does it too, but I'm not
> sure if they cover everything.
I was consider reusing the data from ICAT (which has this information
structured), since I wasn't looking at broad methods defining this. It is
good to know that Secunia is already doing some of this. The problem is,
however, that I cannot put that information readily into a database (like I
have done with Bugtraq, CVE and ICAT) from which I can automatically
extract info.
I was just wondering if someone had done this for Debian specific
vulnerabilites and generated a report that could answer the following
questions:
- which vulnerabilities have been usually fixed in a DSA (probably most
of them have been buffer overflows)
- which type of packages have been usually affected?
- what type of security flaw has that been?
Would a report providing this information be useful to the audit team?
(check the article I linked to in my previous mail)
> I don't agree with Secunia's methods of calculating risk at all.
Why so? Where are they described?
>
> A problem with spending a lot of time on calculating severity levels is
> that it may stop people from contributing what some see as lower risk
> security problems like Cross-site Scripting (which can be bad enough in
> many circumstances). I would much prefer a system where people found and
> patched everything they could - XSS, local buffer overflows, symlink
> attacks - instead of feeling ashamed for finding those things.
I don't actually want to calculate severity levels, I want to see which are
the areas in which Debian has published most vulnerabilities, since it
might:
a) find areas that need more audit work (for example, there have probably
been more DSAs related to 'optional' packages than to others)
b) find areas that have _not_ been audited (sample: "we haven't found any
XSS bug but there are probably lots of them")
c) find packages which have been more error-prone and need to be
adequeately audited every time there is a new release (there might be more
error-prone because they are audited most or because they are full of
security bugs, sample: php packages).
d) find wether we are being proactive enough, that is: have the DSAs been
issued due to internal Q&A work or due to external work? Do we notice
potential issues before they are found out and published out there?
If we had an in-depth analysis of the security vulnerabies that end up
needing a DSA that could give more power to the Security Team to, for
example, refuse packages of a given type since they are known to have
security issues and should go through an audit first.
Just a thought.
Regards
Javier