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."
"7.1 Advance Notification
This document does not address processes for notifying selected groups of users about vulnerabilities in advance of the general population. While such âoepre-release notificationsâ are sometimes done, and in very well-controlled cases can be carried out effectively, they are not a recommended practice in the general case. Because this document addresses only activities that are appropriate for typical cases, advance notification is beyond its scope."
"8.2 Use of Third Parties
In some cases, investigations may be made more effective by the use of people or organizations other than the Finder and Vendor. There is no requirement to use a third party, but in cases where one is used, it should be a person or organization that the Finder and Vendor have agreed to in advance of its involvement. Characteristics of a good third party include sound judgment, freedom from bias or conflicts of interest, demonstrated technical expertise in security technologies, and discretion regarding the handling of the information it is entrusted with to resolve the dispute. Third parties normally serve in a voluntary capacity, as a service performed in the public interest."
Members of the OIS... (From the OIS site http://www.oisafety.org/about.html#1) What companies are members of OIS?
The current members are: @stake, BindView, Caldera International (The SCO Group), Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, and Symantec.
We're actively soliciting software vendors and security research companies to join. Send OIS your feedback on the draft until July 7th! (From the OIS site http://www.oisafety.org/resources.html) "Comments on the Security Vulnerability Reporting and Response Process should be sent via email to draft-feedback@oisafety.org. Comments should include your name, address, and email contact information. Organizations submitting public comments should include the name and title of the person submitting the comments. While OIS will respond to as many comments as possible, because of the anticipated volume of comments, we cannot guarantee an individual response to every comment."
Heil Sig! -Rob
microsoft: there's a bug in our bug disclosure process. apply this patch using windows update.
user: windows update recommends that i install 14 critical updates.
microsoft: you cannot install this patch without all the updates
user *installs 10 updates, 11th fails*
user: uh...
microsoft: it's your problem. btw, the bug disclosure process bug is your problem too.
----
http://www.hellection.com
Section 9
All OIS participants must either look like Peter Norton or Steve Balmer. Minimally this can be preformed by wearing khaki pants, blue denim shirt, and sensible shoes.
No person or organization wearing black, having purple hair, or listening to obscure music may participate as either a Finder, Vendor, Coordinator, or Arbitrator.
Heil Sig! -Rob
I welcome the day when we no longer have security bugs.
"As discussed in paragraph 7.3.7 above, the Finder and Vendor should act in concert to release their respective advisories nearly simultaneously, and only after a remedy is available."
It's all in that last phrase "only after a remedy is available"
This must be microsofts way of shuting up the anti-windows people out there.
Speaking at Defcon 12 - Credit Card Networks Revisted: Pen
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.
1337 Reveals limited disclosure plan
Eight hacking groups join together to set an official standard for limiting disclosure of software security holes.
#1337, Efnet â" Eight computer hacking groups rounded up a three-day Exploits in Computing Forum on Thrusday by formally announcing a coalition against full disclosure of vulnerability information, ending a week of intense speculation, and immediately sparking controversy.
WanSan, TCPuke, NetLoft, HeavySak, BitEvil, SYNergy, HPLat, and DownScope joined together to declare they would immediately begin following a policy of limited public disclosure of security vulnerability information. Members of the coalition who discover new vulnerabilities will omit from their initial public advisories any details about how a hole might be exploited in an attack, and will not include code that demonstrates the bug. Thirty days after the first advisory, a more detailed notice can be released under the rules. Full disclosure of the vulnerabilities will be shared only among the members for âtestingâ(TM) purposes.
"We felt that as responsible industry leaders, we, as a voluntary organization, are going to follow a set of reasonable standards," said DXNo, manager of 1337â(TM)s intrusion exploitation, in an interview.
1337 will also draft a proposed international standard for notifying vendors and the public about newly-discovered software security bugs, following the group's limited disclosure ethic. The organization will admit new members, under an as-yet unwritten set of bylaws. The initial draft of the limited disclosure ethic will limit the disclosure to the home pages of the vulnerable sites.
A chief objective of the group is to discourage 'full disclosure,' the common practice of revealing complete details about security holes, even if publication might aide attackers in exploiting them. The group believes that any type of full disclosure would assist software vendors into patching various vulnerabilities before they can be widely exploited.
Publishing complete information, and sometimes "exploit" code that demonstrates a vulnerability, is de rigueur among many computer security professionals, who argue that malicious hackers can acquire the same information themselves, and that network administrators and security gurus often need technical details to properly defend themselves from attack.
But Culp criticized the practice in an essay published on a Microsoft Web site last month, and blamed "information anarchy" for the epidemic of malicious worms that have struck the Internet in the last year. "It's high time the security community stopped providing blueprints for building these weapons," Culp wrote.
Under the plan, member groups would share detailed information during the 30-day grace period with âoeother communities in which enforceable frameworks exist to deter onward uncontrolled distribution.â The last category would allow member groups to share details with one another. "They're not going to ban it among themselves," says Levy. "They might be willing to limit the public access to this information, but I highly doubt that they'll limit it among each other."
"People have to do it Microsoft's way or they'll have this group telling them that they're acting irresponsibly," says Maiffret. "It's going to drive people into the underground, and could lead to more people breaking into computers." The majority of members in 1337 agree with Maiffretâ(TM)s assessment.
"We are not trying to form a secret society of exploiters," says CKLawz "We are just creating a standard... This represents one of the first process standards between security companies and vendors."
wyZopa1 estimate that it will take one or two months to produce drafts of the proposed RFCs. He emphasizes that the standards would not just limit vulnerability disclosure, but would also spur vendors to be more responsive to security vulnerability reports. "My goal in the RFC is to have equally stringent standards for vendors and exploiters," says wyZopa1. âoeWe worked hard to discover these vulnerabilities, the developers should work just as hard to fix them. Providing them with all our tools without compensation is not what software development is about.â
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Face it. Anyone can do security. All you need is the will, the drive, the talent, and the know-how. Which means, me, the average geek, ex-blackhat hacker, technologist, futurist dude.. can play with stuff, learn stuff, share with others, and build my CAREER off it. Not after this.. This would keep all the knowledge I gain from other professionals, from bugtraq, etc, out of my hands, forcing me to subscribe to these people's services, philosophies, etc... no. I will not. This will not stop hackers, this will only stop the admins who are trying to keep everything together. This will be a tax on the admin who manages 1500 machines, and has no time to read simple stuff.. Hackers, don't need bugtraq. Its useful, its a resource, etc, but if they want in bad enough. Fuck em all.
Why don't they ask themselves why is their product so weak and vulnerable, instead? How much of those vulnerabilities were exposed and fixed *because* they were exposed? It's a GOOD thing. There was a bug, people found it, tried reporting it, got told to fuck off, published it - and the bug got fixed.
Funny that a New York Times Ad was rotated into this story...
They, in particular, excel at non-disclosure... Perhaps they'll be joining this "Organization for Internet(Information) Safety"
Heil Sig! -Rob
2.2 Phases
The basic steps of the Security Vulnerability Reporting and Response Process are:
# Discovery. The Finder discovers what they consider to be a security vulnerability (the Potential Flaw).
# Notification. The Finder notifies the Vendor and advises it of the Potential Flaw, and the Vendor confirms that it has received the notification.
# Investigation. The Vendor investigates the Finderâ(TM)s report in an attempt to verify and validate the Finderâ(TM)s claims, and works collaboratively with the Finder as it does so. # Resolution. If the Potential Flaw is confirmed, the Vendor identifies where the Flaw resides, then develops a remedy (in the form of a software change or a procedure) that eliminates or reduces the risk of the vulnerability.
# Release. In a coordinated fashion, the Vendor and the Finder publicly release information about the vulnerability, along with its resolution.
Now look at this under the context of the recent MS Passport Vulnerability to see how effective this process is.
As an aside, this draft is backed by MS and SCO, amongst other companies. It'll be interesting to read the amount of bashing this gets over the weekend.
All you need is the will, the drive, the talent, and the know-how.
Well, that's a short list just anyone could sort out in a weekend
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
FYI, the 11 companies involved are:
u ardent
Microsoft
@stake
BindView
SCO
Foundstone
G
Internet Security Systems
Network Associates
Oracle
SGI
Symantec
-Mani
Well that will stop people from releasing the information.
The Kruger Dunning explains most post on
Why would anyone follow these guidelines? It might piss off these companies, but anyone who really cares about security would realize that giving the vendors the exclusive right to disclose flaws (regardless how much time has passed or how many systems have been compromised) prevents people from making an informed decision to yank these programs until a solution is identified.
Mapped to the real world, it's like some idiotic Police Chief knowing damn good and well that several pizza delivery drivers are mugged every night when they go into a four-block area... but refusing to say anything - not even warning these drivers to avoid the area for a while - until after the muggers have been convicted, sentenced, and in prison for a month.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
You have to sign a non-disclosure agreement in order to see the anti-disclosure plan
While this is no doubt disturbing, there's more to the security world than those 11 companies. Yes, some of the security firms involved are high profile and there's a lot lost in their soul-selling, but there will always be BugTraq - and there will always be other researchers who don't believe in this shit.
can't hurt me.
rehab, captain ahab, you're chasing the wrong fish!
- @stake
- BindView
- Caldera International (The SCO Group)
- Foundstone
- Guardent
- ISS
- Microsoft
- NAI
- Oracle
- SGI
- Symantec
Considering their backgrounds, it is sad that @stake and ISS are involved in an anti-disclosure group."Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
The document mentions only Finder, Vendor etc. What about the user? Suppose the Finder tells the vendor, "Hey, there's this bug in Passport Password Reset". Now the vendor (Microsoft) works in conjuction (collusion?) with the finder, and says, Look - this is a trade secret. Wait for a few months, and we'll watch if anyone's using this bug except us.
Poor Joe ServicePack is the one affected, and he figures nowhere in this scheme of things.
If you keep throwing chairs, one day you'll break windows....
Living in the D.C. Metro area, I was very upset when hearing that the D.C. Police Chief had been against revealing the make of the snipers' car when they finally found it out. Once this information was released, the snipers were caught in 2 hours or so, IIRC.
I agree with the parent poster - this seems like an apt analogy. At least if a non-negligible number of bugs, patches, fixes, or workarounds, even if just temporary, come from unexpected sources outside of the vendors or finders.
Shouldn't the title to this story have been "Group Discloses Anti-Disclosure Plan"?
Tarsnap: Online backups for the truly paranoid
Probably 90% of security holes are buffer overflows...
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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
I think it was around 7-8 years ago they went from "releasing cool tools" to "whoring for big consulting contracts and never, ever releasing anything cool." Have you seen their website? Microsoft's website looks more "authentic" than that crap.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
US Democracy:The best person for the job (among These pre-selected choices...)
US Democracy:The best person for the job (among These pre-selected choices...)
90%? What a joke! That's the biggest bullshit i've ever heard in my life. Mod parent down, funny, because that is a total JOKE!!!!!
Thanks.
I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...
;)
I'm sure he'll have some interesting things to say.
Large print giveth, and the small print taketh away
Thank you! Please don't let everybody know how to hack... Job security ya know...
||| I still can't believe Parkay's not butter.
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.
Full disclosure only stimulates vendors to come up with a patch quickly. It's their fault in the first place there was an exploitable bug. We don't need a law to regulate bug disclosure. This is security through obscurity and it doesn't work. Information will leak and a limited number of people will take advantage of it anyway, while I, the use won't know to shut that buggy service down.
Let's call a spade a spade: companies like Microsoft should be liable for negligence when they sell buggy software for lots of money, at least for the amount of money the user paid for the software. Now, instead, not only do they want to be able to release buggy software with impunity, they also want to get free testing and bug fixes from users, and all that without the embarrassment and risk of having their bugs revealed.
There are precedents where doing this could be plain wrong, like in the last WebDAV vulnerability in IIS, that was discovered after being actively exploited by black hats. Hiding the facts will not stop crackers to exploit something they know first, and will only make victims unaware of what could or have happened with their sites.
The only time most of those guys release patches in a reasonable timeframe is when they're looking at a PR or a lawsuit debacle. If I find a vulnerability, I'll shoot the vendor an email and see if they hop to it or not. If they hop to it, great. If they blow it off, then it's posted publically before they patch.
That's how it'll always be handled by some people that find vulnerabilities. That's the way it's been handled in the past, and the world hasn't ended. It's just occasionally uncomfortable for a big player that sat on their ass for too long. Tough toenails. They need to put the same energy into just fixing reported problems that they do into trying to put this complicated mechanism in place to cover up problems that they fail to addres
obscurity will eventually always fail as a security protocol.
Being the cost-minimizing/profit-maximizing organizations that they are, they will always wait forever to incur new costs (like fixing bugs) until somebody "lights a fire under them." That's why quick public disclosures is important, because the bug *will* be discovered by the bad guys sooner or later, so it is better to fix it soon than wait for later.
Ok, so next time, choose not to participate.
Next!
H
Two problems :
:
... :-(
1) Exposing a vunerability will make any company that does not try to "repair" them liable -> costs money
2) Having to "repair" the vunerability because of the liability-problem will cost money too
Now look at the proposed "solution"
a) Don't tell anyone you know about he problem, and you can use "plausable deniability" (Just let your opponent *proove* you knew about it). Result : Nobody can effectivily sue you, and the threat of loosing money is gone.
b) The liability-threat (aka : losing money) is gone, and so is the incentive to develop a "repair" to the problem.
Guys & girls, this is a win-win situation !
For the companies that is
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!
This is surely part of Microsoft's Secure Computing Initiative ... If we can't make software more secure, at least we can decrease the public's perception that it's insecure. See no evil, hear no evil, speak no evil.
"And you are dying so slowly, you believe to be living" - Bertrand Besigye
I find it hilarious how every now and then some vaguely important sounding organization creeps out of the shadows, proclaims something completely unfounded regarding a topic that is undergoing heated discussion, yet nobody has ever heard of them before.
This happens all the time with those "think tanks", then all those bogus agencies selling certification in the security industry...
Is this a new art form or something? Hacking the stupid mainstream media who will just present it as fact if it comes from an important sounding institution, even if there is not much more about it than a letter box in Aruba?
Sheesh.
It /isn't/ an apt analogy. In your analogy, if the Police Chief released the information, it could only benefit the population by warning the pizza guys to steer clear of the area for a bit until the muggers are caught.
What it wouldn't do, is tell other muggers "oh that four block area is a great place to pick up pizza guys!" or help the muggers in any way.
In order for your analogy to be accurate you need to factor in some kind of disadvantage to disclosing the information such as mass hysteria, or starvation for the pizza dependent inhabitants. In which case your analogy breaks down because it's no longer an idiotic Police Chief being irresponsible, it's damage limitation.
It can be interesting and it improves ones ability to read, write, and understand code.
Doing so in a public forum can create reputation capital for ones consulting services or products. In some cases may lead to employment.
Some folks are truly motivated by the desire to see vendors patch their software. This is sometimes a result as well.
The companies involved in the OIS have already established their reputation. They aren't doing this for fun. It is to their advantage to prevent others from competing with them. The idea here is to keep interesting research and discussions closed while charging naive corporations thousands of dollars to attend talks which provide little to no real information.
Look the goal here is to make money and that is noble and good. In order to do this people shouldn't just give away all of their hard work and research. The problem here is that these guys are protecting their bottom line under the guise of Internet Safety. It is a bit disgusting but I think might be irrelevant in the long run. Since SecurityFocus is part of this plan though I bet the mailing lists over there will be short lived. Oh well nothing lasts forever.
Dave Aitel makes some rather lucid observations.
You are wrong. It will help the muggers because once that information is known, the smarter muggers will stop going there. Also, the public will expect the Police (MS, etc..) to be more visible (Release a patch) in the area to keep the other muggers away.
to ensure that a vendor can optimize delay, denial, and obfuscation aimed at supporting the maximizing of profits. How stupid does this organization think programmers are? We'd have to be "eat up with the dumb*ss" to buy into this scheme.
...you can rest assured that I'm going to disclose it widely, anonymously and with great fanfare.
-- Even if a god did exist, why the fsck should I worship it?
How many "Day Zero" exploits is it going to take before this concept is abandoned?
Actualy, they were caught on differt warrent. The police chief never had the make of the sniper's car.
that the exploits will be released to the net anyway, in the form of hackers who don't give a shit anyway.
This will be yet another attempt by MS and co to stymify OSS (illegal to report bugs) and control the world.
The world will respond with code red III and Slammer II.
Indeed, this is going to propel OSS onto the desktops of the masses.
Once the vendors get to control what information gets disseminated about their bugs the cost-effective way of dealing with these bugs will not be to fix them, but rather to just sweep them under the rug.
Yeah, some minor security holes might be patched, but something major, like the MIME/filetype exploit in Windows, or gaining administrator privilege though using window events -- the suckers that are tough to fix -- count on this class of vulnerability to stay hidden.
All OSS has to do is be cool. Do honest work, if you find a bug, report it to everybody and get the fix out quick. I'd rather anyone hacking my system to have a tiny window of opportunity than be able to exploit at will.
Or to put it another way, OIS mandates that more black hats are looking at the holes than white hats.
OSS means exactly the opposite.
Is this truly the only Earth I can live on?
Last year they tried to fool the IETF with something like "responsibility rfc" which was almost the same as this. The IETF just said "No" to it. An archived copy is available Now they are trying the same in a m$ owned circle. Since symantec is part of oisafety, don't expect real discussion about this on bugtraq. Some bashing of this nonsense is available on the "Full disclosure" mailing list: thread The response to the draft rfc was Free Hacker Manifest"
Step 1) Write better code
Step 2) See Step 1
Step 3) What the hell did you miss Step 1 and 2?
Photons have mass!!?? I didn't even know they were Catholic...
http://www.computer.org/proceedings/sp/1046/104602 14abs.htm
This was presented at the "2001" Oakland conference, held in 2000.
There were some fascinating points in the presentation that weren't spelled out in the paper.
Disclosure didn't matter for the exploits they studied. That's right, didn't matter, for good or for ill. The rate of exploitation in the wild didn't spike after public announcements. The exploitation rate didn't go down after patch release.
Events that did matter included the public release of scripted exploits, and the cycle of the academic year.
Exploitation rates finally faded away over time but the fade-out curve didn't relate to patch adoption or availability. In fact, sometimes an exploit would flare up again after fading away. The authors attribute the decay of the exploit rate to boredom on the part of attackers, and maybe to the gradual replacement of vulnerable software.
If they're right, the policy lessons that follow (you're getting my opinion here) are:
o Disclosure is harmless and should be allowed
o Patches should be encouraged. They won't stop the next Code Red but they have benefit for anyone willing and able to install them.
o Distribution of attack scripts has a high social cost.
o When a vendor ignores a problem until there's an attack script in the wild, you've got a dilemma.
Here's a brainstorm: full liability for the damages caused by exploitation of a security hole. Liability lands on the vendor if they ignore a bug report that includes a demonstration attack, lands on the script author if the attack goes into the wild before there's been a chance to fix the problem.
Will may my life so much easier, I wont have to worry about reading about the latest bug or attack.
I'm sure my boss feels so much safer.
All kidding aside, its all about covering their butt, not to admit problems. But does this increase their liability? They are withholding vital information from their customers about faults in their products.
If the automotive industry did that, they would raked over the coals.
Whats next, make it illegal to discuss bugs in a public forum with out their permission.. errrr wait..
---- Booth was a patriot ----
No, didn't download the PDF. I see no need, it's an obvious cover up scam in advance.
With that said, it's not broke, and there's no need to fix it. This attempt is a fancy way to have yet again another CYA deal for "saving money" and maximizing profits at consumers expense, and avoiding responsibility. The only proven "lesser of various legitimate evils" method is the one that is used now where the exploit is noted, the vendors are notified, then the general public. At best I'd say a few hours or 24 hours, or skip it and release it if it's in the wild already. Having an open ended patch time is what it appears to be, a way for the profitable vendors to delay fixing and treat bugs and exploits amd to treat them as minor issues. They've been doing that forever,obvious as all get out to even a casual observer, the other way just works better, that's what the empirical evidence shows. Both ways have sucky things to them, the current way of almost immediate public notice just sucks less. And the main reason WHY is that individualk consumers of said product can make up their minds based on severity of threat if they should alter or take down critical systems before they get hosed. That's THEIR business, NOT the business of the random software vendors they got their software from.
Vulnerabilites exist, so there needs to be maximum pressure put on the software vendors to patch, with no consideration to lost profits. No other industry gets that dodge, it's time for it to end. Closed source, expensive and propietary has long passed it's "new industry" honeymoon period they were given of being given slack on liability issues. Open source and free is a totally different animal, it's completely different. As soon as you give them any open ended time period wiggle room, the bean counters will step in and delay patches, and they also allow release of unproven and usually bugy stuff, again, profits over liability. It's been proven so many times now this should be a no brainer. That's the main reason there still exist huge holes, profits over quality and liability at every chance. That's the evolutionary shift that's needed, profits are OK, but should be secondary to quality of product released as "production quality" to the consumers. If software company A doesn't care about that, that shows their over all mindset. Companies that make billions and still foist "caveat emptor" on their consumers are doing a gross disservice to the public in general, and having it some sort of standard or law that they can sit on exploits and bugs forever and be ho hum about it is negligence to the public. It's time to get past that notion. A patch can be likened to a tangible good RECALL, if they just called them that, just use a different word, maybe it would make more sense to them and consumers. I will guarantee you, if any normal product sitting on the shelf gets enough recalls, that product is REMOVED from the market, you aren't allowed to sell it any longer. WHICH IS IT? I read this here all the time, "My blah blah version blah blah is just a tool and etc" CORRECT! It's a tool, and if you keep selling a tool to the public that constantly breaks and needs a recall,or is so flimsy it falls apart with normal use, it's DEFECTIVE MERCHANDISE and shouldn't be allowed to be sold. Can't do it? Tough luckski then, open source and free it,as in speech and beer, or move on to another business that you might be competent at..
IMO, back to bugs and exploits, it also needs to be released as soon as possible so that many more people can help with the patches and fixing, too, the "open source" method is by far superior in most instances.
OR, these closed source software vendors can accept the SAME liability that tangible products have, and be LIABLE for damages. They want to call their software a "product", they want their IP to be patentable and copyrightable and whatnot to have huge megabucks level financial value,they are lightning quick to use their lawyers to defend their products, GREAT, NO PROBLEMS if that is what they
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?
This was a tough call. Sure, the snipers were caught quickly afterwards at the truck stop: but the police didn't know that they were homeless vagrants who wouldn't know they'd been tagged. That was the call the police had to make, and it was not an easy one by any count.
I for one thought that while releasing the information proved to be the fortunate decision, it was not the smart one.
Note that it doesn't have to be this way. Suppose it looked like this:
Now that would put some teeth in the process.
as if this even matters. sure its polite to tell a company about a bug before posting the exploit but how many companies pay attention to bug reports of security vulnerabilities without the added incentive of public proof that its broken.
If you bought a stroller for your child and somebody else discovered that it had a serious design flaw that could cause it to collapse suddenly when going over bumps seriously injuring the child inside would you (a) prefer that the manufacturer was told silently so that they could take their time to release a fixed version or (b) know as soon as possible that your stroller has serious flaws even if it could not immediately be fixed so that you have the option to stop using it?
It's the same question: its all about companies preventing embarrassment at the (potentially serious) cost of consumers.
Admittedly, I have only perused the draft, but it does appear to be another attempt to prevent large companies from being "outed" when they choose to release software that is not ready or is poorly designed. Bugtraq, the Internet Storm Center and the Insecure.org Mailing List Archive do a fine job of lighting a fire under the responsible buttocks when necessary.
I have yet to hear of a posting to one of these lists that could be considered responsible for actual "trouble".
I would assume that if someone were planning on taking advantage of a vulnerability, they would look for one that hasn't yet made it to these lists.
Read, L
Okay, so you're strengthening my point. The initial analogy didn't mention anything like that, and was making out that the withholder of information was stupid and irresponsible.
What I'm saying is that this is a bad analogy because on the surface it makes the reader think "oh yes the Police Chief is an idiot, and by inference so are those who withhold vulnerability information," when in actual fact, if you look at the situation more closely, the Police Chief is acting in this way for a well thought out reason.
It never ceases to amaze me how easy it is to strengthen an argument by duping people with convoluted analogies that miss a vital point. It is a common technique of misdirection in debate and discussion.
My case in point, Donald Rumsfeld saying yesterday re. the WMD fiasco, "we haven't found Saddam yet, but there aren't any people running around saying he doesn't exist. We just haven't found the WMD yet," or words to that effect. Again, a bad analogy because the difference is that, we KNOW Saddam existed before the war, and he has gone into hiding. True the weapons could have been hidden in the same way, but we don't KNOW they existed and that's the proof the public are asking for.
This is all getting a bit OT, but I guess my point is to BE WARY of bad analogies.
They didn't even release the real information to most of the police who were looking for them. Coincidence? There also are some curious questions about how no jobs no money people could travel freely, back and forth from the islands, where they stayed, got to use government target ranges, and some other things, ie, who was supporting-or should I say "running" these "snipers" anyway?
You really think it was a coincidence all this went down around DC in front of some critical voting about a new anti terrorism bill? Really? A coincidence that at least one of them was both recently military trained and also under some psychiatric care with drugs? A coincidence?
coffee-aroma-wakee wakee time
It's a lot easier to audit one C/C++ implementation, even if it is something gigantic like a compiler, than it is to audit an entire system's worth of code. In any case, it's the translation stage that provides safety -- when the language can guarantee safety, it translates directly to C/C++; when it cannot, it inserts runtime checks in the translation. The only way this would fail is if the translation stage was too aggressive in optimizing and failed to insert a runtime check where it should have. This doesn't happen very often though, and is in any case much better than C/C++, where the only runtime checks are those inserted by the programmer (who in large systems almost always leaves out checks that were necessary).
The other argument is often "well it's bad coders' fault, not C/C++'s fault." If that's the case, then all major software, including nearly all Linux security and server software, is coded by bad coders. There's been overflows in: Apache, Sendmail, BIND, Samba, OpenSSH, the Linux kernel, ProFTPd, WuFTPd, XFree86, and many more.
So basically, if you use C/C++, it's going to be insecure, no matter how much effort you put into it. Even OpenBSD, which spent an inordinate amount of effort auditing their code, has had a remote root exploit in their default install (and many more in stuff not installed by default but commonly used).
My preferred solution would be to use either a high-level safe language where feasible (SML, Java, Scheme, etc.), or to use a low-level safe language where not (Cyclone is probably the best of these).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Maybe this is my fault for being neither a hacker nor a security expert, but exactly what effect would this "standard" have? There are lots of people who don't agree with the idea of sweeping problems under the rug, and lots of them are in a position to find flaws in commonly used software. This resolution certainly doesn't have the force of law; if I find a remote exploit for a Windows server, what's to stop me for publishing it if the company ignores my report?
Maybe this could get woven into corporate contracts, but without broad-based support this "standard" doesn't seem worth the paper it's printed on.
Ugh. Another flame-war sparked by those who favor "disclosure". In the minds of some, "disclosure" and "exploit code" are synonymous; anyone who feels differently must be in the "anti-disclosure" camp. As expected, the "disclosure" mujahedin trot out their usual line of reasoning, which is roughly: "if sploits are outlawed, only outlaws will have sploits." And of course, they make the same shrill, baseless ad hominum accusations of sell-outs and cover-ups. Please.
I have some bad news for those who believe that the value of vulnerability information will somehow be irretrievably reduced simply because exploit details are not included.
Let's go to the videotape, shall we? In 2000, Arbaugh, Fithen, and McHugh at the University of Maryland published an IEEE article on the lifecycle of vulnerabilites, based on CERT/CC reporting data. The article contains quite a bit of empirical data and several useful charts. Here is the money quote:
The notion that somehow it doesn't matter if the exploit code is published is just hogwash. It does matter. It makes a decisive difference in the rate of incident occurrences, as the data shows. The number of zero-day exploits is a tiny trickle compared to those that come later, after scripts are widely circulated.
Vulnerability disclosure is critical to making systems more secure. Vulnerability information needs to be freely available to the public. But posting detailed "proof of concept" code that can be easily converted into an automated attack script is another thing entirely. Posting exploit scripts in public forums is, as P.J. O'Rourke once put it, "like giving whiskey and car keys to teenage boys." It is reckless, and irresponsible. Self-important glory-seekers who wail that their livelihoods are at risk, it seems to me, need to develop some more marketable skills.
Frankly I don't much care about what they've got in a disclosure framework, as long as it meets at least a few requirements:
First, most vendors will reasonable deny that a security flaw exists unless there is code or a process that clearly exploits the flaw. This is reasonable. After all, if a flaw is only theoretical, and not a clearly exploitable, it really is not clear and present danger. The problem occurs when exploit code exists but the vendors denies it's existence. The vendor will then use the official lack of exploit code as a reason not to solve the problem, which has in the past caused the subsequent release of exploit code to the embarrassment of the vendor.
Second, vendors have sometimes been slow to release fixes. This is also reasonable. It is probably very expensive to expedite fixing of security flaws. It is probably much cheaper to put the fixes in the pipeline and let the coders get to them as time permits. Of course, this may cause problems for users, but that is no different from the rest of American corporate culture where no problem exists until the costs of the lawsuit and the negative publicity approaches the cost to fix the problem. Fortunately, in software we do not need such drastic action to effect change. The flaw and exploit code can simply be released to the public.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Or it could be a win-lose situation, with closed-source vendors losing and open-source vendors winning, in the long term. After customers see how their open-source products have very few security problems, and those that pop up are fixed quickly, and after they deal with never-ending security problems with their closed-source systems (despite this stupid new "plan" of theirs, which will just eliminate a lot of their incentive to close the security holes, but do nothing to keep hackers from learning of them and exploiting them), the customers will slowly move to the open-source vendors.
That is, is Ashcroft and company don't have open-source software banned for helping terrorists...
Go and read the F*ING document, you idiots!
Where the HELL did you find any anti-disclosure in there? First of all, that document details a _process_, in which vendor and finder (of flaw) act together to overcome a security flaw.
It details how can a finder contact the vendor, give firm deadlines on response time from the vendor, how the interaction between finder and vendor goes, assures the finder that something Is Being Done, and protects the user from disclosure of a flaw for which there are no fix.
It answer things like "What if vendor and finder cannot agree on whether a flaw is a security flaw?" and "What if vendor thinks it has fixed the flaw but finder disagree?"
What it *DOESN'T* do is prevent disclosure.
If communication breaks down -- if finder and vendor simply cannot agree, the process simply stops. If the process has stopped, the finder can go right ahead and do anything they want.
Once the process is finished, the finder can go right ahead and disclosure anything they want.
The finder should only avoid disclosing the flaw when the process is working: he is satisfied with the feedback from the vendor, no fix is yet available, and no exploit or disclosure of the flaw is available on the internet.
Since the only result of a disclosure in such a situation is help crackers against defenseless users, no reasonable person can object to that.
So either whoever chose that title hasn't read the document, or he is more fond of wracking destruction and financial damage to the helpless. In the first case, he is an idiot, in the second, he is an asshole.
(8-DCS)
-= Freedom of Choice - Freedom of Voice =-
http://nothackers.org
Open Independant Security Research
Publicly express your security issues / flaws today,
after all...
you could always choose not to turn on a computer.