Disclosure Debate - yet again

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 10/08/04

  • Next message: Ernst Lopes Cardozo: "Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities" 
    Date:         Fri, 8 Oct 2004 16:57:24 -0400
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    Ok, I don't want this discussion to go on again to the extent it has in the past, but its a Friday and I'll let some through.

    Just to add a possibly new perspective to this issue that I personally haven't seen discussed before;

    We (TruSecure) are in the process of finalizing something we call the "Global Risk Index". There'll be a note and survey about this next week, but in the meantime its purpose is to assess the current risk levels faced by an average 1000 PCs in an organization. We then track this, hour by hour or day by day, using thousands of data points, in the hopes of painting an accurate picture of the current state of security.

    Further to that, we then apply "Controls", or counter-measures you might call them, which mitigate those risks. They have varying effectiveness, and affect different aspects of risk (e.g. they might reduce the frequency of a risk, but not the cost, or it may be effective against an anonymous exploiter, but not against someone with privilege...etc...)

    Anyway, in developing this model we came to the point where, in defining the risks, we had developed the factor of "Known" versus "Unknown", in terms of an attack.

    Often the debate about responsible disclosure is focused on the zero-day exploit. Its the doomsday bomb, the thing we fear the most it seems...but is it really?

    We had come to use the Known/Unknown to represent this in our model. Known virus, known worm, known exploit tool, etc... versus zero-day whatever. In pondering this I got to the point where I wondered just what value there was in having a factor for zero-days. You have to think about all of this in terms of the following;

    a) We're only concerning ourselves with attack paths that successfully causes some bad outcome. There are many bad outcomes, it doesn't matter.

    b) Bad outcomes have a cost, and happen so often, varying according to the attack path.

    c) Controls mitigate either the cost, frequency, or both of a given bad outcome due to a given attack path.

    Known versus Unknown in the zero-day sense would have added a layer of abstraction between (a) and (b), meaning we'd have more costs, and frequencies to determine (and just how do you determine a good estimated cost for the unknown bad outcome of an unknown attack path?)

    If, however, you say that "Known" means anything for which a patch, definition, or workaround exists, and unknown means zero-day *AND* everything you've not patched against, or every virus where a definition is available but you haven't updated...the zero-day thing takes on a whole new meaning.

    After all, what's the real difference between an attack based on an unknown vulnerability, and one based on a vulnerability for which a patch exists, but you haven't applied it? You may be one of the millions who've never heard about either the vulnerability or the patch.

    Further, when you talk about mitigators, many apply equally to known or unknown/zero-day. The ASP.Net Authorization issue is just one good example...proper coding or installation of appropriate security measures means you're not susceptible to the attack described.

    A zero-day is likely going to cost you slightly more...a support phone call (or many), several (many) hours of diagnostics or audit review (possibly at 2:00am), downtime prior to implementing a workaround or fix...but these days this is happening less and less across *ALL* organizations. You have a problem, look around, see everyone's having a problem, look again, find a mitigator or two to try, etc...

    Don't get me wrong, I'm not being overly simplistic. We saw a ton of people who got Blaster despite the fact it wasn't a zero-day. Tons more get Sobig or MyDoom or whatever, every day. Most people who got Blaster thought they had the patch deployed, or didn't even know about it at all. They had to do all of the things anyone would have to do when there's a zero-day (or at least most of them.)

    Zero-days could result in millions of credit card records being stolen without anyone noticing, sure, and that's worse than it would be if there was a patch for the web server vulnerability that would allow the theft. But such zero-days already exist, are in use, and we're not detecting them. Nature of the beast, unfortunately, we detect anomalies that we know about.

    That said, their exploitation is few and far between, so far as we can tell, and as such, don't actually represent significant risk. Risk yes, but not statistically significant to the 1000 PCs in any given organization.

    So back to the disclosure discussion...

    If we accept, and no doubt there's strong opposition around, that zero-days aren't as much risk as we've previously believed them to be, we should be able to more properly focus our fear/concern/efforts.

    There are certainly people with more than adequate technical skill to write exploits. Some are good, some are evil, some are in-between (yes, Jason, there is grey space.) There are even more, several magnitudes more, people who don't have that level of skill, but have enough to take a PoC exploit and modify it sufficiently that it by-passes current detection, or acts even more maliciously than the original author intended.

    They aren't able to reverse engineer, but they may be able to modify someone else's shellcode. As PoC becomes more and more "user friendly", its getting to the point where they can simply write a script and the PoC will do what the script says...which is even worse, IMO.

    Someone's study last year (I believe, and someone give me the reference so I can keep it please) found that most attacks were based on known vulnerabilities for which patches existed for quite some time. There's been heated debate over whether time-to-exploit is reducing, but historically it hasn't been a huge factor. If all this damage can be caused by non-zero-day, why is it we fear the zero-day attack?

    I say disclosure of a vulnerability versus the time an effective mitigator is available is always non-zero. That means, we always have effective mitigators against any zero-day attack. That we don't use them is our problem!

    Maybe its just human nature, but we do this with everything. There was a flood in a town not far from me earlier this summer...they'd had one 2 years before which was called the 100-year flood...yet this one was worse again. You'd think that it would've had far less impact than previous years...but nope, it was worse. Most people seemed to say "What do I do?" or "I thought it wouldn't happen again in my lifetime!", neither were effective at preventing their loss. Most people ignored all of the good suggestions made the last time, and so suffered again this time.

    So in all of this disclosure stuff, there is one definite thing I feel can be done to "improve" the situation. Namely, making available fully functional PoC code. As Drew points out, providing a code snippet that points to the exploitable culprit gives technically capable people what they need. It does not give anything to the people who want to write a script to control a bot someone else wrote. Martin argues that if they weren't given a heads up, they'd spin their wheels and waste resources (some they may not have) coming up with it by themselves. I say, if they're capable, and interested, they'll probably not look for the eEye spot, and instead look for the technique elsewhere in the same code (or in the patched code)...there's more in it for them to do that.

    But when the PoC code gets published, or found, and cleaned up or made "user friendly", I find that deed equal to the release of a worm itself. Who do such people think they're helping? Countless Administrators hoping to show their boss' that they are, indeed, vulnerable? We have been doomed to this PoC madness because of this excuse for years...can we just not accept that once some competent technical body looks at the claim, and says "Yep, its an issue", its enough?

    If we did, a full and immediate disclosure might look like this;

    "I discovered a vulnerability in MS <insert product name here>. MS confirmed its a problem. MS has published a warning, with the following list of effective mitigators;

    <mitigator list goes here>

    The vulnerability results in <insert bad outcome here> if mitigators are not in place. Expect a patch within the foreseeable future...

    End Call" (sorry http-equiv...;-])

    So yeah, technically competent people would run around and write exploit code (maybe, maybe some.) We might even get a worm before the patch is available. If, however, the mitigators are effective, and we're given enough information so we can choose between them, what more do we need??? Our insatiable appetite for information says "WE NEED IT ALL!!!", granted, but the reality is we don't...or at least the vast majority of us don't. Least of all (if at all) is our need for a "user friend" PoC exploit that lets us choose what our exploit will do.

    Can we get consensus, even if just among the current group in this discussion, that "user friendly" PoCs are bad?

    Cheers,
    Russ - Senior Scientist/NTBugtraq Editor
    TruSecure Corporation (or is it Cybertrust?) 

    --
NTBugtraq Editor's Note:
Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field.
--
  • Next message: Ernst Lopes Cardozo: "Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities"