Re: Exploits matter.

[security curmudgeon <jericho () attrition org>]

: > The difference betwene $US 30 and $US 200 is big. The difference between $US
: > 30,000 and $200 is even bigger. I mention that because I believe your . in
: > the 30.000 value really means 30,000, which is a huge difference to us
: > Americans. Regardless of your use of . vs , anyone versed in math or
: > economics could lecture on percentages of 30 and 200, or 200 and 30000.

: There is no need to flame bate, I only inserted the dots (yes, European style,

I apologize, it was not my intention to be flame bait. I just wanted to 
make the distinction that trying to track value, while very intersting, is 
definitely outside the scope of what a VDB can realistically track.

: > As applies to OSVDB, if I am doubting our ability to intellectually track
: > "public vs private", then the debate over the dollar value should not be
: > very relevant, especially in a historic context.

: So if I understand you correctly, for you "public versus private" is 
: more useful in the decision whether to worry about some rumored attack 
: then the difficulty for a given attacker? Or to ask it differently, I 
: would worry based on the cost to one attacker (i.e. under the assumption 
: that there is always one), not on the amount of attackers, whereas you 
: seem to worry about the amount of attackers (based on their access to 
: the attack)?

OSVDB wants to track public vs private (and likely a more granular 
metric), unrelated to someone using us as a source on 'should we worry?'. 
I certainly hope no one uses us as a definitive source on the status of an 
exploit other than a link we may provide to it. We also have no intention 
of tracking the amount of attackers, be it companies like Immunity or Core 
or trying to determine how many bad guys may be out there that developed 
it.

: > In the last few years, we have also begun to discuss and implement a
: > framework for tracking *vendor confidence*. It isn't only researchers that
: > are flaky and ill-equipped to handle vulnerability disclosure. =)

: Interesting, I did not know it was already so far in software 
: vulnerability domain. So in essence there is already for a long time a 
: mechanism to describe "claimed to be privately available" in the 
: vulnerability databases (and apparently from your heated reaction, this 
: was hard won. Kudos!). That means Dave's original question still holds: 

It was, and its still in its infancy. Despite that, every VDB uses their 
own form of resarcher confidence. Unfortunately, most (including OSVDB) 
can only do it based on personal history of working on a VDB. Our goal is 
to actually define that confidence level, show our 'math' and publish it. 
The knowledge I have of vulnerability disclosure as pertains to the 
researchers and their reliability should not die with me. Anyone should be 
able to look at that history should they need it (e.g., hiring purposes, 
risk assessment).

: why is it then so important that it is public (i.e. for free for all) or 
: commercially available for $4000 from a reputable vendor to anyone that 
: can pay that amount? I mean a free public exploit is more likely to 

I don't think it is that important, it's an interesting metric to track. 
We run into this often; we think "it would be neat to track X" then debate 
it to death, determining if it is valuable to users, relevant to the 
database or will end up having more issues and uncertainty than value.

: I can imagine that that is because of the different views.
: The researchers see their confidence scores as selling point, a higher score
: means more importance hence more market value (in money, prestige, Kudos,
: whatever). The good ones also want something to clearly distinguish them from
: the wannabes with good marketing.

True, but it can bite someone in the ass too. If they publish 100 
vulnerabilities and 20% end up being incorrect, that could later haunt 
them if they try to work for a company doing vulnerability research.

: > overhaul to our classification system regarding exploit availability, as
: > well as "vulnerability framework" vendors, free and commercial, to share
: > with us a better understanding of what they have in their arsenal without
: > giving away details that are a detriment to their commercial advantage.

: Interesting. So the market isn't picking up on it but it is not clear yet why.
: Your proposal later on looks like a serious step towards it.

I think it is obvious personally. If I say there is a remote overflow in 
product X, that is all it really takes for a skilled researcher to start 
dissecting the software and figure it out. There has to be a serious 
balance in what you advertise you have as far as 0-day, or you run the 
risk of giving away too much and devaluing your product. Immunity 
advertises the exploits they have for published vulnerabilities because it 
gives nothing away. If they say "we have a remote for apache" that is 
vague. If they say "we have a remote for apache related to header 
handling", that likely significantly reduces the time required for a third 
party to find the issue.

: Good point. I think this (and my confusion about why it matters) comes down to
: different levels of assurance one is seeking. I recently (at the CC conference
: 2 weeks ago) sat in a panel next to Oracle and Microsoft as the "big software
: companies", informally representing the smartcard community. I was struck at
: the different realities the two domains have and this seems to apply here
: also.
: 
: In the general software domain, the products are so huge that there is
: inevitably huge amounts of bugs in there and have essentially next to no
: defense in depth so in many cases it is exploitable also. So there your
: timeline point is valid, i.e. the time between possibility to patch (with a
: need to patch, maybe here is the public/private discussion?) and the
: weaponized exploits is the window of opportunity. So anything that reduces
: this (silently patching by the vendor, quickly patching, pressuring to
: avoid/delay disclosure, etc) is useful. Your proposal would create very
: interesting measurements on timing especially.

Absolutely. Unfortunately, due to time and lack of information, it could 
likely only be done with the big vulnerabilities; the Microsoft, Oracle 
and Cisco remotes. The 'lesser' vulnerabilities, even if being widely 
exploited (e.g., SQLi), don't come with enough information to do that 
analysis I bet.

: Interesting discussion, thank you!

Very =)

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave