Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Matthew Wollenweber (mjwcyberwart.com)
Date: Thu Oct 08 2009 - 08:58:26 CDT
It might be a little more informative to add an extra field to various
databases. I say maybe, as unless the databases actually test the
exploits accuracy would be questionable. But I think the marginal
difference between the terms "private/rumored" and "private/for sale"
doesn't examine the underlying problem -- which is what Matt Olney and
I believe Dave were getting at. The practical distinction between
public and private doesn't mean much. For $1000 you can have the
exploit from Immunity -- or you can likely get it for free if you know
someone. That's not a particularly high bar, but most organizations
treat private exploits (and by that I mean anything not on milw0rm,
metasploit, or bugtraq) as an unfathomable problem. So they obviously
Now the above is precisely the problem (IMO). It's pretty easy to buy
"private" exploits. It's pretty easy to write simple stack buffer
overflows that you'll find in vast amounts of in-house software. It's
pretty easy to use a packer to get past most or all AV. All of the
above will generally be near completely immune to most defenses. These
are insurmountable problems in the eyes of most businesses. When
considering defending against these threats, you might have better
luck convincing them to train school kids to defend against the
military. This is why they focus on whether one can easily download
the exploit or not. If so, then they have a problem that's in their
process to tackle. If not, it's too hard and they accept the risk.
They prefer the latter.
When you consider that it's "pretty easy" to do several things that
are insurmountable problems to most businesses then you really begin
to see the problem.
Defense security people like to gripe about people that release
exploits. It's a natural response given that their lives are made more
difficult. Ultimately, they're going to have to tackle the above type
problems, and (IMO) full-disclosure pushes them one step closer to
admitting the current security balance isn't acceptable. Since many
exploits are more difficult these days, there's going to be more
private/for-sale exploits and hopefully they'll begin to tackle these
problems. Until then, I expect to hear much more whining.
On Wed, Oct 7, 2009 at 8:17 PM, c0lists <listscarnal0wnage.com> wrote:
> On Wed, Oct 7, 2009 at 7:49 PM, security curmudgeon <jerichoattrition.org>
>> On Wed, 7 Oct 2009, c0lists wrote:
>> : Because all those databases are incomplete it would be nice if "someone"
>> : would start putting that information in their db to say immunity has the
>> : exploit or core impact has the exploit.
>> It would also be nice if these companies would provide a little better
>> public mechanism for disclosing that information, that can be easily
>> referenced by a VDB. Dave posted to the list about the recent
>> vulnerability, but there are hundreds more Immunity developed with no
>> easily referenced date or details.
>> Because vulnerability information is valuable, we also run into the
>> problem of not knowing if two companies have the same vulnerability
>> figured out, if a vendor's recent announcement about fixing an 'overflow'
>> is the same one as a researcher's, etc. This is becoming a big headache
>> for VDBs; the VulnDisco work by Evgeny is a good example.
> I agree. It would seem to be in their best interest to allows maintainers of
> exploit databases to have access to the exploit metadata even if it wasnt in
> real time (perhaps quarterly) and would be very little overhead. Most of the
> updates go into their monthly "download our new version" or "updated
> moduels" emails anyway.
> That certainly doesnt address all the issues you brought up but would be a
> step in the right direction. Maybe Immunity can start :-)
> Dailydave mailing list
Dailydave mailing list