Date: Tue, 22 Feb 2005 04:06:31 -0500 From: Tom Rhodes <trhodes@FreeBSD.org> To: cykyc@yahoo.com Cc: freebsd-vuxml@FreeBSD.org Subject: Re: Adding Additional Attributes to VuXML Message-ID: <20050222040631.20aecb9c@mobile.pittgoth.com> In-Reply-To: <20050221160356.61989.qmail@web50302.mail.yahoo.com>
index | next in thread | previous in thread | raw e-mail
On Mon, 21 Feb 2005 08:03:56 -0800 (PST) Jon Passki <cykyc@yahoo.com> 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 Rhodeshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050222040631.20aecb9c>