Date: Tue, 22 Feb 2005 07:34:36 -0800 (PST) From: Jon Passki <cykyc@yahoo.com> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: freebsd-vuxml@FreeBSD.org Subject: Re: Adding Additional Attributes to VuXML Message-ID: <20050222153436.69324.qmail@web50302.mail.yahoo.com> In-Reply-To: <20050222040631.20aecb9c@mobile.pittgoth.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Tom Rhodes <trhodes@FreeBSD.org> wrote: > 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. 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 :) <risk> <likely>Remote</likely> <likely>Proof of Concept in Circulation</likely> <produces>Privileged Account Access</produces> </risk> Does this make more sense? Jon __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050222153436.69324.qmail>