On Tue, 16 Jan 2007, Josh Bressers wrote:
> Initially, we're going to ignore embargoed issues. Every time a security
> conversation comes up, people start creating overly complex processes to
> handle them. Once there is a concrete team and process, this can be
> investigated. In the meantime, we'll just deal with issues once they're
> public.
The process is quite straightforward imho:
1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
2. Triage
- assess new and updated reports
- eliminate irrelevant reports (package not included in distro...)
- assign score to relevant reports (see below)
- reassess reports considered irrelevant when they become relevant
(new package added to distro...)
- prioritize reports according to their score
3. Remediation
- select a report/issue to work on
- find or develop patches
- check whether the patches fix the vulnerabilities
- deploy fixed packages
Embargoed (i.e. secret) issues can be implemented quite easily by
"polyinstantiation" of these three steps.
An interesting thing is that step 1 and a large part of step 2 do not
depend on the choice of distro. Moreover, step 1 alone generates "just
another vulnerability database". This provides an opportunity for mutually
beneficial cooperation with other subjects (other distros, OSVDB...).
> Based on that idea, I think it's important to fix things in a
> prioritized manner. The way I see this is that it makes more sense to
> invest extra time working on getting a Firefox critical update out
> before say a minor lha temporary file flaw.
This sounds like a task for CVSS: a Firefox critical update will get a
high score due to its the remote attack vector, high target distribution,
and last but not least partial (or higher) integrity and confidentiality
impact (assuming it allows arbitrary code execution) while a minor lha
temporary file flaw will get a much lower score due its local attack
vector, low target distribution (well, it is probably installed on many
systems but most of the time, it is a dead harmless bag of bits because no
one is using it), and lower impact (partial integrity impact, no
confidentiality impact). The availability of exploits can be taken into
account as well.
On the other hand, it is quite easy to get an absurd CVSS score if input
metrics are set sloppily (as demonstrated by many examples at NVD). Some
experience (or guidance) and good judgement is needed.
> The biggest missing puzzle piece is the lack of tools. I'm currently
> working on some tools to more easily track CVE ids via a clever bugzilla
> interface.
Bugzilla may be fine for the remediation step (see above).
But I do not feel it is (in its standard form) the right tool for steps
one and two. It's just too clumsy. Its search dialog is as complex as the
space shuttle dashboard and something as simple as checking whether a
report for a certain CVE has already been filed needs a lot of work. I
am probably biased, inexperienced, or even stupid (*). YMMV.
(*) But the sheer amount of duplicate reports in every Bz database
suggests I am not alone. ;)
On Tue, 16 Jan 2007, Mark J Cox wrote:
> They map each vuln to a product dictionary which we could map to package
> name, but it'll miss those cases where a vulnerability gets reported for
> something that affects multiple products (like some flaw being labelled
> as an Apple flaw when in fact it's in xpdf), or where things affect
> multiple products (a xpdf issue affects many open source projects).
It might be possible to search the source (*) code of all available
packages (maybe even packages not included in the distro) for duplicate or
similar pieces code and find out whether a bug in package A affects
package B because B uses some code from A (or vice versa).
(*) Statically linked libraries from other packages are not addressed by
this approach but they can be caught by other means.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
