Re: cvs commit: ports/multimedia/xine Makefile
From: Jacques A. Vidrine (nectar_at_FreeBSD.org)
Date: 03/30/04
- Previous message: Jacques A. Vidrine: "Re: cvs commit: ports/multimedia/xine Makefile"
- In reply to: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Next in thread: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Reply: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 29 Mar 2004 22:56:46 -0600 To: Michael Nottebrock <michaelnottebrock@gmx.net>
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 / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
- Previous message: Jacques A. Vidrine: "Re: cvs commit: ports/multimedia/xine Makefile"
- In reply to: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Next in thread: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Reply: Michael Nottebrock: "Re: cvs commit: ports/multimedia/xine Makefile"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
