Adding Additional Attributes to VuXML

[Tom Rhodes]

On Mon, 21 Feb 2005 08:03:56 -0800 (PST)
Jon Passki <cykyc at 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 Rhodes