lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 14 Nov 2003 23:51:42 -0500
From: "Russ" <Russ.Cooper@...on.ca>
To: "Steven M. Christey" <coley@...re.org>,
	<bugtraq@...urityfocus.com>
Subject: RE: Vulnerability Disclosure Formats (was "Re: Funny article")


If it was recommended to the public that they report their medical issues along some "guidelines", such as those suggested by Steve, people would be dropping like flies.

First, let me give a deep bow to Steve's ongoing and significant efforts in the vulnerability reporting arena. I don't think anyone thinks about this issue as much as he does.

That said, I think Steve spent too much time in school...;-]

He acknowledges;

"One challenge is that there are many researchers who are first-timers, so a common advisory format probably wouldn't find 100% adoption.  But it sure could help a lot."

and I agree, adoption of some format would help a lot. Adoption of a single language would help more, IMO, and so too would adoption of the concept that a vulnerability disclosure isn't anything more than empirical research, but we don't live in such a perfect world.

Instead we live with all sorts of Toms, Dicks, and Harriett's discovering all sorts of things, some actual vulnerabilities, some fodder for others to turn into vulnerabilities, and very little of it done for anything more than the pure exhilaration of discovery itself.

Given how far anyone who releases vulnerable code is from being able to prevent malicious attacks against their code from happening, the fact that anyone is willing to devote their own time and effort, for the pure fun of it, to helping them fix that ..."stuff"...has to be seen as pure gravy by those developers. Instead, unfortunately, its often not.

Appreciate that I think anyone who releases malicious code, be it in the form of Proof of Concept or actual worm, should serve time in a Russian prison. There's simply no excuse. eEye has done a great job of providing more than enough information about exploits over the past 2 years without, IMO, writing the basis for malicious code. IMO, they consciously choose to change the way they write their advisories. I've my own opinion about how disclosures turn into exploits which may be at odds with others, granted.

But to suggest that we need to place any more burden on discoverers, prior to us being able to acknowledge their will to not use their discoveries maliciously, is, IMO, insane.

There are very few discoveries that cannot be used for profit of the discoverer. To suggest they should consider posting it this way, or that way, only distances them further from disclosing. I'd rather get it raw in broken English, than to  suggest they resubmit it in some "better" format. I'd also rather get it from them when their prepared to release it, rather than have them disclose it to who knows who to get it formatted better.

What Steve refers to, IMO, is the consumer of such reports (most of you), not the initial recipients (e.g. the lists who in turn forward it to you.)

Remember, Steve's goal is to make it simpler to use public reports to assess vulnerability. To minimize conflict between sellers of such information when an entity attempts to compare reports. This is all well and good for corporations who want to minimize the cost of assessing risk, it has nothing to do with discoverers who are reporting to the public for free (albeit they may have a motive.)

Despite the number of discoverers who regularly post to our lists for free, we, as receivers of such information, still need to make that process easier for them, and, more valuable to them. If we hope to keep such reports coming to the public realm free of charge, as opposed to dealing with 0-day worms that demonstrate newly discovered vulnerabilities, we must embrace the discoverers more than we already do. Asking them to do anything more than they already do, IMO, is counter-productive to that goal.

Thor Larholm proposed the idea of a "Union" to me. While I don't like the concept of union's in this day and age, our field is one that could benefit from such an idea wrt discoverers. They are far too often bashed (and I have been guilty of this), and often not recognized for what they do.

Granted, there are far too many of them who use their discoveries to get their 15 minutes of fame, a platform from which to castigate everyone who might consume their information. Shame, good researchers show themselves to be otherwise motivated sometimes. They don't do this due to improperly formatted advisories, we see it in their demands for letters for their resume suggesting they are great, or their inability to do anything other than recommend a feature be disabled.

OIS may be a great idea for how companies should ask for reports, and Steve's template thoughts make for a great basic format, but neither consider what happens when someone actually discovers something. The first thing they typically need is immediate confirmation. "Can you verify this?", "Does it work that way on all versions?". The discoverer, prior to actually submitting the discovery for public consumption wants to know the real scope of what they've discovered. They may be sitting there with their jaw dropped because their initial thinking is the world's going to come to an end due to what they've found.

On my list, first time or inexperienced discoverers frequently, more often than not, over dramatized the effects of their discovery. I'm not saying they are inexperienced, or unskilled, but it does seem that the effect of the discovery seems to make them over enthusiastic, or overly paranoid. They can envision a way for the exploit to be a killer, they haven't stopped to think about how likely that is to happen.

Sending it out for small peer review; which whether anyone other than me acknowledges it or not, happens when you send something to one of the security mailing lists...is their way of finding out whether they're full of it or not.

At this point in the process, I, as a receiver, don't care how its formatted. Of course the requisite information needs to be present (what OS, what product, how), but as long as the report is written credibly (i.e. it explains what they did and the effect they perceived it to have), its my job to figure the rest out. If not me, then who? The rest of the world should be sent in a tizzy because some schmoe claims something??

I don't perceive the task of Vendor X to be any different. If they receive a credible report, its their job to figure out if its true or not. That they might receive 10,000 reports a day, making the task of determining credible difficult, isn't the problem of the reporter. Imagine if 911 didn't do anything until you provided them with the suggested details Steve offers?

We aren't, IMO, anywhere near the time when we can suggest such things to discoverers. Before we do we have to announce a way for them to be acknowledged, compensated, and embraced. We have to differentiate them from the "hackers", "crackers", skript kiddiez", and other denigrating terms, more than we try already.

Microsoft announced a $5mm war chest to catch malcode writers, and I think that's a good idea. I would have liked, however, for them to announce a $5mm war chest to go to discoverers, like Netscape's old "Bug Bounty". Maybe they feel that would have been too quickly spent, but I know far too many discoverers who are still working on Windows 98 because the cost of researching on more modern platforms is prohibitive.

Anyway, bottom line, be thankful we get anything, in any format.

Cheers,
Russ - NTBugtraq Editor


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ