From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 20:56:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EE516A4CE for ; Mon, 29 Mar 2004 20:56:48 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D00D943D2D for ; Mon, 29 Mar 2004 20:56:47 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 2F3AC5482B; Mon, 29 Mar 2004 22:56:47 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id B7A956D465; Mon, 29 Mar 2004 22:56:46 -0600 (CST) Date: Mon, 29 Mar 2004 22:56:46 -0600 From: "Jacques A. Vidrine" To: Michael Nottebrock Message-ID: <20040330045646.GD5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Michael Nottebrock , Oliver Eikemeier , FreeBSD Security References: <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4068B881.4010304@gmx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security cc: Oliver Eikemeier Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 04:56:48 -0000 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