Dailydave mailing list archives

Re: Exploits matter.


From: security curmudgeon <jericho () attrition org>
Date: Wed, 7 Oct 2009 23:49:57 +0000 (UTC)



On Wed, 7 Oct 2009, c0lists wrote:

: > Ten thousand or not, I cannot download the exploit from Immunity's web
: > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks
: > that metric, that is flagged as 'rumored/private'.
: 
: Then perhaps someone should update OSVDB to include "for pay" 
: exploits/tools as a category just like bugtraq/bid does with comments.

It's a good idea, but opens up additional issues from a VDB perspective. 
If the exploit is available for pay (e.g., via CANVAS), we flag it as 
such. Three months later it is published via milw0rm. Is there value in 
having it flagged 'for pay' and 'public'? Or do we need to then consider 
adding a better date history? We currently track 7 dates, one of them 
being 'exploit published' (public). An 8th date field for 'exploit 
developed' perhaps?

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

: there is a big difference (to me) between rumored/private and for pay.

Yes. For a simple classification system, rumored/private was a better fit 
given:

- Exploit available (public)
- Exploit unavailable (none exists)
- Exploit rumored / private (exists, not public)
- Exploit unknown

This is very simple, but the best we wanted to do originally. Times have 
obviously changed, and adding a little better abstraction is in order. 
'Rumored' by itself has no value, especially long term. The question is 
now how best to expand it without getting too granular and losing focus.

We'd love any input on this.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave


Current thread: