Slashdot Mirror
Group Releases Anti-Disclosure Plan
dki writes "SecurityFocus reports that the Organization for Internet Safety (OIS), a group of 11 of the largest software and security companies, has released a public draft of a proposed bug disclosure standard. The document outlines a process for reporting and disclosing bugs that aims to eliminate releasing exploits to the general public. Not surprisingly, the OIS was founded out of a Microsoft-hosted security conference. Comments on the draft will be accepted until July 4th; the final copy will be released at the Black Hat Conference in Las Vegas."
This makes me wonder - who can be a wonder of OIS? Just anyone? Only people with pertinent projects? Only companies? What about groups like the Debian maintainers or the core kernel devel team? My impression from the article was that it was company or corporate institution-exclusive.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Personally, I've always thought that a good disclosure policy would be one that informs the software's source of the problem and then waits some period of time befoer disclosing to the public.
Of course, I'd reccomend a very short wait time, probably between 48 hours and one week. Just enough time to solve the problem if enough resources are diverted to it but not long enough to allow anyone to ignore the problem until later.
This proposal basically calls for the public to act in the same was as an employee would at finding a bug in the software. Perhaps I missed something here but if a bug is sourced in the public domain it should be disclosed there as well.
If they want to put me on the payroll, I'll QA and report their software using this convenient bug ticket they've provided;)
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
While this is totally bogus, perhaps we just should let them have their little secrecy club. You know, see how well they do compared to other vendors who are more open about their bugs.
But really, if there's some exploit in some app/service everybody should know immediately - the only solution to an exploit is not always a patch fix from the vendor. You could shut down the service, if applicable, tweak some parameters to dodge the exploit, filter some packet, etc. Or you could even fix the exploit yourself in some instances (in the code that is).
But hey, who can blame them for wanting to not disclose this info, they're the only ones who can/are allowed to fix the bugs. :-)
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
Like, 12 year old gas huffers, shut-ins, malcontents.... uh, hackers, and... crackers?!?
You fail to understand the nature of most security incidents I see.
The people who actually discover the vulnerabilities are the security consultants, IT professionals, independent researchers, academics, etc. then the malcontented kiddies and gass huffers take those proof of concept scripts and use them to "hax0r"...hence Script Kiddie...
If you don't release the exploit information and example code until after it's patched you just saved everyone a giant headache. Don't believe the myths. Those teenager hax0r d00ds 99.5% of the time DO NOT find any new vulnerabilities. They just take the proof of concept code from the security bulletin, set up a scanner to randomly find hosts with the exploitable service and get their hax0r on.
Cut out the window between publishing the vulnerability and the patch and you just saved every sysadmin a big headache.
IOW, it's back to the bad old days when Microsoft didn't bother trying to fix exploitable software at all.
Sheesh, evil *and* a jerk. -- Jade
To me, it looks as slowly, we can't trust any software anymore because of this policy. I mostly stopped buying MS products because of this, and a few more companies will find out sooner or later that I'm not their customer anymore.
And even if I could analyze the source code, I don't have the time to do so, especially with big projects like sendmail, or PostgreSQL that I use a lot.
Ok, so next time, choose not to participate.
Next!
H
Someone finds a hole.
They'd like us to sit on our arses while they take their time fixing it.
Meanwhile, some bad ass mofo finds the same hole, and exploits it.
It's the threat of imminent disclosure that makes the vendors fix their fucked-up software - to delay is merely to invite problems.
I repeat - fuck 'em.
oh brave new world, that has such people in it!
Does this mean that all undocumented behavior is considered a security flaw?
Quite the contrary. According to the definition, undocumented behavior is perfectly acceptable, even if it has obviously unwanted consequences.
It's all in that last phrase "only after a remedy is available"
See, that's a very funny way to do it. They are trying to accomplish what by this? Remember the SQLSlammer?? How long has the "fix" for the vulnerablilty used by the SQLSlammer been available?? How hard did the worm hit?? I don't care what the group thinks it's going to achieve with their recommendations on vulnerability reporting, with the companies involved, it won't do any good. Even when Microsoft has the fix available, they are still embarassed and owned by the "next big worm". Unfortunately, it is starting to screw the rest of us as well. Case in point, the aforementioned Slammer worm. Even though there was a fix available, and the worm cannot infect my Linux box, it sure fucked up my internet access for a while.
Humor follows, read at your own risk
As an aside, I, as "the Finder", have discovered a huge vulnerability in the Internet itself, Microsoft products. Now, when can I get "the Vendor" to fix this? My recommendation is denying all Microsoft products access to anything, anywhere.
For those who describe their systems as 'boxen', do you order multiple 'boxen' of corn flakes also?
Bugtraq is one of those 11 companies. (Bugtraq is part of Symantec)
A challenge: create an Open alternative to BugTraq
I have registered the domain names opentraq.org and opentraq.net. I am willing to have them resolve to DNS servers belonging to a group of volunteers who wish to start and maintain an Open alternative to the BugTraq website. (GNU? Mozilla? Anyone else interested?)
I will continue to renew the registration as long as someone wants to continue the project. If necessary, I may be willing to transfer ownership at no cost after the project becomes established and is maintained by a reputable (i.e., non-commercial) group of volunteers.
moto411.com
I don't think the parent is insightful at all. I think it's kneejerk. Imagine a complex piece of software, a complex exploit, and a couple thousand users of the vulnerable software. The company responsible is made aware of the exploit and sets about to fix it. The fix involves more than switching to strncmp() or something trivial like that, so fixing the bug takes a couple days. Meanwhile, the thousands of customers have to be notified and convinced to upgrade when a patch is released. If the exploit is published with code the threat to every single user of the vulnerable software increases, probably exponentially. This is because each installation of the software is vulnerable to attack, basically, by people who understand the exploit as published (and those who knew about it prior to publication, but they're not relevant to this analysis ...) and when code and examples are published the number of people who can invoke the exploit increases massively.
A reasonable window of opportunity for the programmers to issue a fix and protect the users before explicit details on comprimising the software are published such that any malicious dilettante can invoke them is a good thing.
Dismissing it out of hand as "security by obscurity" misses the point and is mere sloganeering without reflection.
A lot of companies writte lousy code. A lot of companies want to cover up their lousy code. I'm not disagreeing with those statements. Nor am I disagreeing with the sentiment that if compamies wrote secure code to begin with this wouldn't be an issue except to note that that's a fantasy ...although there's lots of room for improvement of the industry's code we're still talking about complex systems and there will always be (1) bugs and (2) bugs involving security.