Adding Additional Attributes to VuXML

[Jon Passki]

--- Tom Rhodes <trhodes at FreeBSD.org> wrote:

> 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.

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