On Tue, Mar 30, 2004 at 02:00:01AM +0200, Michael Nottebrock wrote: > If VuXML would provide a fine-grained > classification of security issues (not by severity, but by type: privilige > escalation (incl. root/excl. root), local/remote denial-of-service, > buffer-overflow-but-no-exploit-known, etc, etc), users could customize > portaudit to forbid access to packages or just warn about them from a set > of rules (which would ideally also allow to make exceptions by portname and > other criteria - I realise that's quite a wishlist, but since you asked... > ;-)). It so happens that in the past month or so there has been quite a discussion on a closed vendor security list (mostly large Linux distros + some UNIX vendors) regarding severity rating systems. It's really hard, and it's really subjective. CVE does not assign severity, largely because they do not feel that it is part of their role. Attempts to create systems such as you describe (types of vulnerabilities) have bogged down: some of the better thought out proposals result in 4-6 dimensions. As you probably are aware, it can take a lot of time to research and accurately describe a single vulnerability. I don't know what other's standards are, but before I add something to VuXML, I: (a) track down the original report of the vulnerability (b) confirm it does or does not affect our port by source code review (I skipped this once and got burned) (c) determine what versions of the port are affected (d) get an idea of the impact in order to focus the description of the vulnerability (e) collect as many high quality references to the vulnerability as possible This is about as much work as I'm willing to do :-) Additionally classifying the bug along four to six dimensions could easily double the time to document it. My impression from the discussions I mentioned above is that the (full time, paid) security teams of many vendors are not prepared to invest that kind of time for every reported issue. We do not have a full time, paid team (or AFAIK even a single individual) to do this, either. On the other hand, many use simple high/medium/low ratings, but are dissatisfied by them due to their necessarily gross misrepresentation of most bugs :-) e.g. Some folks will skip fixes because they were rated `low', when in fact *those folks* really need the fix (due to local configuration or what have you). The only reasonable option for the security conscious (IMHO), is to avoid applications with *any* reported security issues until one has read and understood that issue. This is pretty close to what Oliver's portaudit does (I think). Cheers, -- Jacques Vidrine / [email protected] / [email protected] / [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"