From dan at langille.org Tue Feb 1 16:27:18 2005 From: dan at langille.org (Dan Langille) Date: Tue Feb 1 16:27:19 2005 Subject: postgresql security issue Message-ID: <41FFD79A.19863.4D2E7E31@localhost> Does this warrant a vuln entry? http://secunia.com/advisories/12948/ -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ From nectar at FreeBSD.org Wed Feb 2 07:57:44 2005 From: nectar at FreeBSD.org (Jacques A. Vidrine) Date: Wed Feb 2 07:57:46 2005 Subject: postgresql security issue In-Reply-To: <41FFD79A.19863.4D2E7E31@localhost> References: <41FFD79A.19863.4D2E7E31@localhost> Message-ID: <20050202155740.GB14170@lum.celabo.org> On Feb 1, 2005, at 6:25 PM, Dan Langille wrote: > Does this warrant a vuln entry? > > http://secunia.com/advisories/12948/ Seems so ... thanks! Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From dan at langille.org Wed Feb 2 09:48:32 2005 From: dan at langille.org (Dan Langille) Date: Wed Feb 2 09:48:34 2005 Subject: postgresql security issue In-Reply-To: <20050202155740.GB14170@lum.celabo.org> References: <41FFD79A.19863.4D2E7E31@localhost> Message-ID: <4200CBA4.21479.50E7C5DE@localhost> On 2 Feb 2005 at 9:57, Jacques A. Vidrine wrote: > > On Feb 1, 2005, at 6:25 PM, Dan Langille wrote: > > > Does this warrant a vuln entry? > > > > http://secunia.com/advisories/12948/ > > Seems so ... thanks! Cheers, So... if there isn't one there by tonight, I'll play with submitting a patch. -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ From cykyc at yahoo.com Mon Feb 21 08:03:57 2005 From: cykyc at yahoo.com (Jon Passki) Date: Mon Feb 21 08:04:00 2005 Subject: Adding Additional Attributes to VuXML Message-ID: <20050221160356.61989.qmail@web50302.mail.yahoo.com> 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 trhodes at FreeBSD.org Tue Feb 22 01:06:45 2005 From: trhodes at FreeBSD.org (Tom Rhodes) Date: Tue Feb 22 01:06:48 2005 Subject: Adding Additional Attributes to VuXML In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> References: <20050221160356.61989.qmail@web50302.mail.yahoo.com> Message-ID: <20050222040631.20aecb9c@mobile.pittgoth.com> 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 cykyc at yahoo.com Tue Feb 22 07:34:37 2005 From: cykyc at yahoo.com (Jon Passki) Date: Tue Feb 22 07:34:40 2005 Subject: Adding Additional Attributes to VuXML In-Reply-To: <20050222040631.20aecb9c@mobile.pittgoth.com> Message-ID: <20050222153436.69324.qmail@web50302.mail.yahoo.com> --- 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 nectar at FreeBSD.org Tue Feb 22 11:42:02 2005 From: nectar at FreeBSD.org (Jacques Vidrine) Date: Tue Feb 22 11:44:36 2005 Subject: VuXML.org improvements Message-ID: <20050222194200.GA27003@lum.celabo.org> 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 nectar at FreeBSD.org Tue Feb 22 11:54:43 2005 From: nectar at FreeBSD.org (Jacques Vidrine) Date: Tue Feb 22 11:56:00 2005 Subject: [Fwd: cvs commit: ports/security/vuxml vuln.xml] Message-ID: <421B8E01.6060006@FreeBSD.org> > -------- 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 wollman at khavrinen.lcs.mit.edu Tue Feb 22 11:56:21 2005 From: wollman at khavrinen.lcs.mit.edu (Garrett Wollman) Date: Tue Feb 22 11:58:15 2005 Subject: VuXML.org improvements In-Reply-To: <20050222194200.GA27003@lum.celabo.org> References: <20050222194200.GA27003@lum.celabo.org> Message-ID: <200502221956.j1MJuI5J028546@khavrinen.lcs.mit.edu> Very nicely done. -GAWollman From nectar at FreeBSD.org Tue Feb 22 12:26:14 2005 From: nectar at FreeBSD.org (Jacques Vidrine) Date: Tue Feb 22 12:26:15 2005 Subject: Adding Additional Attributes to VuXML In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com> References: <20050221160356.61989.qmail@web50302.mail.yahoo.com> Message-ID: <421B9563.9090201@FreeBSD.org> 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 nectar at FreeBSD.org Tue Feb 22 12:29:39 2005 From: nectar at FreeBSD.org (Jacques Vidrine) Date: Tue Feb 22 12:29:41 2005 Subject: Adding Additional Attributes to VuXML In-Reply-To: <20050222153436.69324.qmail@web50302.mail.yahoo.com> References: <20050222153436.69324.qmail@web50302.mail.yahoo.com> Message-ID: <421B9631.7010901@FreeBSD.org> 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