From owner-freebsd-vuxml@FreeBSD.ORG Mon Feb 21 16:03:57 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BBB616A4CE for ; Mon, 21 Feb 2005 16:03:57 +0000 (GMT) Received: from web50302.mail.yahoo.com (web50302.mail.yahoo.com [206.190.38.56]) by mx1.FreeBSD.org (Postfix) with SMTP id 2F5AD43D1D for ; Mon, 21 Feb 2005 16:03:57 +0000 (GMT) (envelope-from cykyc@yahoo.com) Received: (qmail 61991 invoked by uid 60001); 21 Feb 2005 16:03:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=x0fAJ3WhK1DHYQcMA94OB4sl3Aud2Vw+QFJXbCfg9jPA6A+7QuU4+Jhj6v8/Qe8PsLiGZEJQkSOLZ/k3ON8ibDqXOpnrk9WEmqjAGBd92PwNG1Tiz5g46VpvzqYkYdMuBCvCOA+JdRnkm7R/YpIbDBqw0tWuRgvuzdpW8pXlC0E= ; Message-ID: <20050221160356.61989.qmail@web50302.mail.yahoo.com> Received: from [65.173.207.2] by web50302.mail.yahoo.com via HTTP; Mon, 21 Feb 2005 08:03:56 PST Date: Mon, 21 Feb 2005 08:03:56 -0800 (PST) From: Jon Passki To: freebsd-vuxml@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cykyc@yahoo.com List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 16:03:57 -0000 Hello All, I would like to discuss risk attributes and see if they should be included in VuXML as some new optional elements. What I would like to see are possibly two new elements added that describe the likelihood of the vulnerability and what the vulnerability produces. Neither of these elements would try to directly communicate the impact of the risk (which is site-specific), rather certain attributes that can objectively described the vulnerability. Also, this is not a taxonomy, although it may start to resemble one. It's to provide consistent information across vulnerabilities. When I think of likelihood, I think of some of the following examples: --) Configuration needed for successful exploitation (default or non-default) --) Needed Account Access (non-anonymous, anonymous, none) --) Location of Exploitation (can be performed remotely, needs to be local) When I think of the production of the vulnerability, I think of some of the following examples: --) Network information (host names, IP addresses, MAC addresses, etc.) --) Account information (account name, individual account password, credential reuse, privileged account access, etc.) --) System/Service Information (directory names, file names, configuration information, recursive resource usage, etc.) What I'm asking is if it makes sense to add these two _optional_ elements (or perhaps similar concepts). If it does, then I'd like to start a discussion on the exact content (one bikeshed at a time...). Sincerely, Jon Passki __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 09:06:45 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7C8E16A4CE for ; Tue, 22 Feb 2005 09:06:45 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 043B643D46 for ; Tue, 22 Feb 2005 09:06:45 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-230-188-82.dc.dc.cox.net [68.230.188.82]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id j1M96gKw039416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2005 04:06:44 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Tue, 22 Feb 2005 04:06:31 -0500 From: Tom Rhodes To: cykyc@yahoo.com Message-ID: <20050222040631.20aecb9c@mobile.pittgoth.com> In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> References: <20050221160356.61989.qmail@web50302.mail.yahoo.com> X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-vuxml@FreeBSD.org Subject: Re: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 09:06:45 -0000 On Mon, 21 Feb 2005 08:03:56 -0800 (PST) Jon Passki wrote: > Hello All, Hi Jon, > > I would like to discuss risk attributes and see if they should be > included in VuXML as some new optional elements. What I would like > to see are possibly two new elements added that describe the > likelihood of the vulnerability and what the vulnerability > produces. Neither of these elements would try to directly > communicate the impact of the risk (which is site-specific), rather > certain attributes that can objectively described the > vulnerability. Also, this is not a taxonomy, although it may start > to resemble one. It's to provide consistent information across > vulnerabilities. > > When I think of likelihood, I think of some of the following > examples: > > --) Configuration needed for successful exploitation (default or > non-default) > --) Needed Account Access (non-anonymous, anonymous, none) > --) Location of Exploitation (can be performed remotely, needs to > be local) > > When I think of the production of the vulnerability, I think of > some of the following examples: > > --) Network information (host names, IP addresses, MAC addresses, > etc.) > --) Account information (account name, individual account password, > credential reuse, privileged account access, etc.) > --) System/Service Information (directory names, file names, > configuration information, recursive resource usage, etc.) > > What I'm asking is if it makes sense to add these two _optional_ > elements (or perhaps similar concepts). If it does, then I'd like > to start a discussion on the exact content (one bikeshed at a > time...). I'm really sorry for how late this email is but I thought you should get an honest reply. :) The issue with both of these elements is not just time but the proof of concept code. Think of it: When some bugs are located in the code, an exploit isn't really released to the public. That would probably have a huge effect on administrators who need to patch a large amount of systems. It would mean they need to work harder and faster. Personally, I know that I lack the time to invent an exploit for every issue that exists in software these days hehe. Another thing, would you really want all of those exploit files sitting on your servers? Or the time to test them successfully on your specific config? Right now, we just check the version and likelyhood of effects on FreeBSD. Then we publish. There has been a case or two in the past where an item wasn't listed due to the inability for an exploit to affect FreeBSD. Yet, we're human and can make mistakes. Which is why if there is any doubt we'll list the port just to be safe. All in all, I think that it would be just too difficult and time consuming both on our side and the side of the administrator. -- Tom Rhodes From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 15:34:37 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBDB316A4CE for ; Tue, 22 Feb 2005 15:34:37 +0000 (GMT) Received: from web50302.mail.yahoo.com (web50302.mail.yahoo.com [206.190.38.56]) by mx1.FreeBSD.org (Postfix) with SMTP id D84D943D1F for ; Tue, 22 Feb 2005 15:34:36 +0000 (GMT) (envelope-from cykyc@yahoo.com) Received: (qmail 69326 invoked by uid 60001); 22 Feb 2005 15:34:36 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=jU1OxmbyvuQ8lnX6wYKNsisJbVUnm1QjklOF5GeXPwTk78/Q8RDAytSxiI00EvpEAbYIesclT+ittH2fk9m6kR781xeRnCZ1KTcW2Sok3HGRkoSj7li/YL1uhn3/UXmMKylDaZRx/zbN2zVd3aD8yuiAzlRpRd44BRCfGQD+8q4= ; Message-ID: <20050222153436.69324.qmail@web50302.mail.yahoo.com> Received: from [65.173.207.2] by web50302.mail.yahoo.com via HTTP; Tue, 22 Feb 2005 07:34:36 PST Date: Tue, 22 Feb 2005 07:34:36 -0800 (PST) From: Jon Passki To: Tom Rhodes In-Reply-To: <20050222040631.20aecb9c@mobile.pittgoth.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-vuxml@FreeBSD.org Subject: Re: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cykyc@yahoo.com List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 15:34:37 -0000 --- Tom Rhodes wrote: > On Mon, 21 Feb 2005 08:03:56 -0800 (PST) > Jon Passki wrote: > > > Hello All, > > Hi Jon, > > > > > I would like to discuss risk attributes and see if they should > be > > included in VuXML as some new optional elements. What I would > like > > to see are possibly two new elements added that describe the > > likelihood of the vulnerability and what the vulnerability > > produces. Neither of these elements would try to directly > > communicate the impact of the risk (which is site-specific), > rather > > certain attributes that can objectively described the > > vulnerability. Also, this is not a taxonomy, although it may > start > > to resemble one. It's to provide consistent information across > > vulnerabilities. > > > > When I think of likelihood, I think of some of the following > > examples: > > > > --) Configuration needed for successful exploitation (default > or > > non-default) > > --) Needed Account Access (non-anonymous, anonymous, none) > > --) Location of Exploitation (can be performed remotely, needs > to > > be local) > > > > When I think of the production of the vulnerability, I think of > > some of the following examples: > > > > --) Network information (host names, IP addresses, MAC > addresses, > > etc.) > > --) Account information (account name, individual account > password, > > credential reuse, privileged account access, etc.) > > --) System/Service Information (directory names, file names, > > configuration information, recursive resource usage, etc.) > > > > What I'm asking is if it makes sense to add these two > _optional_ > > elements (or perhaps similar concepts). If it does, then I'd > like > > to start a discussion on the exact content (one bikeshed at a > > time...). > > I'm really sorry for how late this email is but I thought you > should get an honest reply. :) > > The issue with both of these elements is not just time but the > proof of concept code. Think of it: > > When some bugs are located in the code, an exploit isn't really > released to the public. That would probably have a huge effect > on > administrators who need to patch a large amount of systems. It > would mean they need to work harder and faster. Personally, I > know that I lack the time to invent an exploit for every issue > that exists in software these days hehe. Hmm, I don't think I was requesting PoC or exploit code. Generally, when PoC or an exploit is publicly known it tends to put a fire in some people (the non-paranoids out there - the paranoids patch everything ;) So, if it does exist, or if the exploit is trivial, then that just gets mentioned. One doesn't need to include such code. > Another thing, would you really want all of those exploit files > sitting on your servers? Or the time to test them successfully > on your specific config? > > Right now, we just check the version and likelyhood of effects > on FreeBSD. Then we publish. There has been a case or two in > the past where an item wasn't listed due to the inability for > an exploit to affect FreeBSD. Yet, we're human and can make > mistakes. Which is why if there is any doubt we'll list the port > just to be safe. > > All in all, I think that it would be just too difficult and > time consuming both on our side and the side of the > administrator. Okay, we're not on the same gamma wave :) Nope, no exploit code should be included nor was I requesting that. This is more towards a risk rating structure, but with as much objective and as little subjective information as possible. I see this by defining at least two criteria: likelihood and production. Likelihood is affected by the ability to perform the exploit. If it's trivial or if there's PoC/working exploit, that in general increases the likelihood. Same with it being remotely or locally exploitable. Same with default or non-default configurations. I wish to have elements that could trap these values. They may be programmatically used, or skimmed by a human. E.g. (I dislike the names of the elements below :) Remote Proof of Concept in Circulation Privileged Account Access Does this make more sense? Jon __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 19:42:02 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B14E16A4CE; Tue, 22 Feb 2005 19:42:02 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C61BD43D53; Tue, 22 Feb 2005 19:42:01 +0000 (GMT) (envelope-from nectar@celabo.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id F294E3E2C47; Tue, 22 Feb 2005 13:42:00 -0600 (CST) Received: by lum.celabo.org (Postfix, from userid 1001) id 5234F60047C; Tue, 22 Feb 2005 13:42:00 -0600 (CST) Date: Tue, 22 Feb 2005 13:42:00 -0600 From: Jacques Vidrine To: freebsd-vuxml@FreeBSD.org, freebsd-security@FreeBSD.org Message-ID: <20050222194200.GA27003@lum.celabo.org> Mail-Followup-To: freebsd-vuxml@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Organization: The FreeBSD Project User-Agent: Mutt/1.5.6i Subject: VuXML.org improvements X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-vuxml@FreeBSD.org List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:42:02 -0000 Hello Everyone, I have made a few small changes to the VuXML.org web sites, http://www.vuxml.org/freebsd/ (aka vuxml.freebsd.org) and http://www.vuxml.org/openbsd/ - Date-oriented indices (e.g. entry date index) visually group entries from the same date. - The package name index is more useful, listing individual package names. - Each package referenced in VuXML now has its own index page linked from the package name page, e.g. pkg-squid.html. The index page lists all entries affecting that package. In the case of FreeBSD, a link to FreshPorts.org is also displayed. - For entries which contain a CVE name reference, one may "hover" the mouse over the CVE name to get a pop-up description of the CVE as provided by MITRE. - Each CVE name referenced in VuXML now has its own index page, e.g. cveitem-2004-1308.html and cveitem-2000-0442.html. Those pages contents are generated directly from MITRE's CVE list. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 19:54:43 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F90D16A4CE for ; Tue, 22 Feb 2005 19:54:43 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2A5E43D54 for ; Tue, 22 Feb 2005 19:54:42 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 1AE913E2C47 for ; Tue, 22 Feb 2005 13:54:42 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 6C87E600495 for ; Tue, 22 Feb 2005 13:54:41 -0600 (CST) Message-ID: <421B8E01.6060006@FreeBSD.org> Date: Tue, 22 Feb 2005 13:54:41 -0600 From: Jacques Vidrine Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-vuxml@FreeBSD.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: cvs commit: ports/security/vuxml vuln.xml] X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:54:43 -0000 > -------- Original Message -------- > Subject: cvs commit: ports/security/vuxml vuln.xml > Date: Tue, 22 Feb 2005 19:27:32 +0000 (UTC) > From: Jacques Vidrine > To: ports-committers@FreeBSD.org, cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org > > nectar 2005-02-22 19:27:32 UTC [...] > Corrections: > - An invalid UUID was assigned to a FreeRADIUS vulnerability, and went > undetected since last October. (>_<) Correct it. Hi, This is an interesting, if unfortunate, situation. If you are the author of a web site or application that processes VuXML, you should probably be aware of this specific issue. An entry was created with an invalid `vid' attribute. The vid is supposed to be a UUID (see [1] [2]). Unfortunately, this entry apparently suffered mutilation during cut-n-paste: the last character was dropped. I corrected the error by restoring the last character. I know what that character was "supposed to be" by looking at other entries made by the same committer. (^_^) But since the vid is used as a "key" for entries, VuXML parsing applications may need to take special action to purge the old identifier (20dfd134-1d39-11d9-9be9-000c6e8f12e) from their files/databases. Normally when an entry is in error, we can just "cancel" it, but in this case that isn't possible: even a cancellation refers to the vid. If you have any questions about this, please let me know! Oh, I don't expect a repeat in the future. I'm checking for this kind of mistake now, and fairly frequently. I will likely later add a port to "lint" VuXML files, also. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org [1] http://www.opengroup.org/onlinepubs/9629399/apdxa.htm [2] http://www.freebsd.org/cgi/man.cgi?query=uuidgen&sektion=2 From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 19:56:20 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA2D16A4D2 for ; Tue, 22 Feb 2005 19:56:20 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60D0143D46 for ; Tue, 22 Feb 2005 19:56:20 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id j1MJuIaa028549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA) for ; Tue, 22 Feb 2005 14:56:19 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id j1MJuI5J028546; Tue, 22 Feb 2005 14:56:18 -0500 (EST) (envelope-from wollman) Date: Tue, 22 Feb 2005 14:56:18 -0500 (EST) From: Garrett Wollman Message-Id: <200502221956.j1MJuI5J028546@khavrinen.lcs.mit.edu> To: freebsd-vuxml@FreeBSD.ORG In-Reply-To: <20050222194200.GA27003@lum.celabo.org> References: <20050222194200.GA27003@lum.celabo.org> X-Spam-Score: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.37 X-Mailman-Approved-At: Tue, 22 Feb 2005 19:57:47 +0000 Subject: VuXML.org improvements X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:56:21 -0000 Very nicely done. -GAWollman From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 20:26:14 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D7A016A4CE for ; Tue, 22 Feb 2005 20:26:14 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4739443D1D for ; Tue, 22 Feb 2005 20:26:13 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id AF44B3E2C45; Tue, 22 Feb 2005 14:26:12 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id CFBAB600542; Tue, 22 Feb 2005 14:26:11 -0600 (CST) Message-ID: <421B9563.9090201@FreeBSD.org> Date: Tue, 22 Feb 2005 14:26:11 -0600 From: Jacques Vidrine Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cykyc@yahoo.com References: <20050221160356.61989.qmail@web50302.mail.yahoo.com> In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-vuxml@freebsd.org Subject: Re: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:26:14 -0000 On 2/21/05 10:03 AM, Jon Passki wrote: > Hello All, > > I would like to discuss risk attributes and see if they should be > included in VuXML as some new optional elements. Hi Jon, This topic (or one very similar) has come up before. Please see the thread including this email: http://lists.freebsd.org/pipermail/freebsd-vuxml/2004-August/000036.html. > What I would like > to see are possibly two new elements added that describe the > likelihood of the vulnerability and what the vulnerability > produces. Neither of these elements would try to directly > communicate the impact of the risk (which is site-specific), rather > certain attributes that can objectively described the > vulnerability. Also, this is not a taxonomy, although it may start > to resemble one. It's to provide consistent information across > vulnerabilities. I agree that risk cannot be assigned objectively. This results in some funny things from people who try to do so, such as Secunia's rating system: all ratings include the word critical, from "less critical" through "extremely critical". (^_^) > When I think of likelihood, I think of some of the following > examples: > > --) Configuration needed for successful exploitation (default or > non-default) > --) Needed Account Access (non-anonymous, anonymous, none) > --) Location of Exploitation (can be performed remotely, needs to > be local) > Your meaning is clear enough here. What would be the purpose of including optional elements for these? (Concrete examples, please.) Frankly, if the existing narrative text () for an entry does not address these points at least implicitly, then the text needs revision. > When I think of the production of the vulnerability, I think of > some of the following examples: > > --) Network information (host names, IP addresses, MAC addresses, > etc.) > --) Account information (account name, individual account password, > credential reuse, privileged account access, etc.) > --) System/Service Information (directory names, file names, > configuration information, recursive resource usage, etc.) > I don't think I understand ``the production of the vulnerability'', or these points. > What I'm asking is if it makes sense to add these two _optional_ > elements (or perhaps similar concepts). If it does, then I'd like > to start a discussion on the exact content (one bikeshed at a > time...). Content by example is good, even very early on. General questions that should be answered for changing the content model by adding new items: How would these items by used? By whom or what? Who would provide the information? If it is optional, what would be the consequence of 99% of entries not containing the item? Why shouldn't these items be in an adjunct document, at least initially until the value is proven? Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org From owner-freebsd-vuxml@FreeBSD.ORG Tue Feb 22 20:29:39 2005 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CB8116A4CE; Tue, 22 Feb 2005 20:29:39 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7BAA43D45; Tue, 22 Feb 2005 20:29:38 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 62CDC3E2C45; Tue, 22 Feb 2005 14:29:38 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 87A2B60054A; Tue, 22 Feb 2005 14:29:37 -0600 (CST) Message-ID: <421B9631.7010901@FreeBSD.org> Date: Tue, 22 Feb 2005 14:29:37 -0600 From: Jacques Vidrine Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cykyc@yahoo.com References: <20050222153436.69324.qmail@web50302.mail.yahoo.com> In-Reply-To: <20050222153436.69324.qmail@web50302.mail.yahoo.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-vuxml@FreeBSD.org cc: Tom Rhodes Subject: Re: Adding Additional Attributes to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:29:39 -0000 On 2/22/05 9:34 AM, Jon Passki wrote: > They may be > programmatically used, or skimmed by a human. > > E.g. (I dislike the names of the elements below :) > > > Remote > Proof of Concept in Circulation > Privileged Account Access > > > Does this make more sense? Please explain how they would be programatically used. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org