Slashdot Log In
Schneier On Full Disclosure
Posted by
Hemos
on Tue Nov 13, 2001 04:55 PM
from the interesting-reading dept.
from the interesting-reading dept.
Bruce let me know that he's written a piece on ZDNet (original home of the for the Window of Exposure idea is on Counterpane ? ) about the problems of not following full disclosure. Very well written and does a great job of summarizing why full disclosure works. The original piece from Culp @ Microsoft is also available, along with the PowerPoint that they did.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Remember! (Score:3, Funny)
MS has made a big mistake (Score:2, Insightful)
I am for full disclosure but... (Score:2, Insightful)
Re:I am for full disclosure but... (Score:5, Interesting)
So just hiding information doesn't necessarily make you more secure.
sPh
[1] OK, the Soviet Union had spies inside the project before it started, but that doesn't count!
Re:I am for full disclosure but... (Score:5, Informative)
This is where you can cross the border undetected [house.gov]
This is how to make a Fake ID? [counterfeitlibrary.com]
Well maybe I didn't say every single tiny little syllable but basically I said em, basicly.
Microsoft's answer to Full Disclosure (Score:5, Funny)
Just another example of how Microsoft listens to and responds to customer requests. Have a nice day!
Sometimes you should shout "Fire" (Score:1, Redundant)
Re:Sometimes you should shout "Fire" (Score:5, Funny)
(A) Shout "FIRE!" and get crushed in the panic.
(B) Walk out quietly...who cares about anyone else?
(C) Tell your closest neighbor and hope that they're a fireman.
(D) Pour on gasoline so everyone will get out faster.
Beware of the "Fire" argument (Score:4, Insightful)
The argument that you can't just shout "fire" in a crowded theater entered the law in Schenck v. United States [findlaw.com], 249 U.S. 47, 52 (1919). This was a Supreme Court case concerning whether the government may suppress pamphlets encouraging people to resist the draft. Although I think that case may have been correctly decided (with the distinction being expressing opposition to the draft versus encouraging people to violate the draft law), I wonder if the Court realized they were treading on, or near thin ice, when they used the "Fire" analogy.
So it is with people who use the analogy today. Whenever someone start comparing some kind of speech to shouting "Fire" in a crowded theater, don't get carried away by the emotional appeal but keep an eye on your rights, lest someone try to make off with them.
Grace Period (Score:5, Interesting)
Grace Period
Purpose: Give users a reasonable interval during which to protect their systems against newly reported vulnerabilities
- Begins with public notice of vulnerability, and lasts for 30 days
- Is immediately curtailed if vulnerability becomes actively exploited
Do I read this correctly? Does this mean that when an exploit is shown to exist in the wild, then they immediately switch to "full disclosure" mode? This means that there is now an incentive to put an exploit in the wild: it means you can publish your work. Even if you leak the exploit surreptitously.
I know I must be preaching to the choir here, but, this seems exceedingly stupid. Am I missing something?
...find other ways to protect their customers... (Score:2, Insightful)
blurring out...
What Culp actually said... (Score:4, Insightful)
"Most of the security community already follows common-sense rules that ensure that security vulnerabilities are handled appropriately. When they find a security vulnerability, they inform the vendor and work with it while the patch is being developed. When the patch is complete, they publish information discussing what products are affected by the vulnerability, what the effect of the vulnerability is... and what users can do to protect their systems....
"Some security professionals go the extra mile and develop tools that assist users in diagnosing their systems and determining whether they are affected by a particular vulnerability. This too can be done responsibly...
Fire (Score:2)
Slam.
One thing microsoft is good for... (Score:2)
Computer/network/internet security issues have been around a long time; perhaps now it will be more of a factor in management decision making.
He pegs it with this: (Score:2, Insightful)
Perhaps it was pointed out that codered et al had patches a month ahead of time.
But, in the same breath/stroke it was mentioned by MS that their meathod of informing, distributing about patches/vulnerability was/is "confusing".
And the article by Culp almost says in effect "we don't want vulnerabilities known so we can stop writing patches and bugfixes or do it when "we" feel like it".
The whole "rely solely on the vendor" schtick is coming full circle it seems.
The author pointed out that is the way "it used to be" and it seems Microsoft is pushing for it to be that way again.
Share the vulnerability with the press (Score:2)
2. Write code to exploit the vulnerability.
3. Arrange with an industry journalist to demonstrate the exploit.
Then it comes down to MS PR vs. journalistic integrity.
P.S. Don't even THINK about doing this unless you're cool with MS buying all the trade rags...
technet security slight (Score:1, Interesting)
http://www.microsoft.com/technet/treeview/defau
That innocent little list o' worms (Score:5, Insightful)
- Code RedMicrosoft worm.
- LionLinux worm
- SadmindSolaris worm that affected Microsoft OS's (*ack* if you can call them OS's!)
- RamenLinux worm
- NimdaMicrosoft worm
Now that means that a "representative" list of worms would contain 50% Microsoft worms, 40% Linux worms, and 10% Solaris worms. It's good to see Microsoft presenting a legitimate picture of what's going on. C'mon!! Windows practically breeds worms! Linux has had how many? 4, 5? Morris, Ramen, Lion, Adore. That's all I can come up with. Now, do I start listing the Microsoft worms (not to mention virii)?...-------------
All your sig are belong to us.
Even PR is exploitable...heh (Score:1)
Ouch...
and referring to the Culp article again, with the DMCA in effect, it is a lot easier "to shut ppl up about MS's vulnerabilities than it is to fix them.
OOOoooo...that really hits home.
Regardless (Score:2, Insightful)
While it is certainly up to the vendor to release as bug free code as possible, I disagree with his exoneration here. "If you don't know how to use it, don't" holds true regardless of what OS we're talking about. A Unix sysadmin that doesn't patch his/her boxe(s) is as much to blame as an MS sysadmin who fails to do so as well.
Whether or not the amount of exploits for IIS are a direct result of how widely it is used outside of the "heavy metal" internet server arena is anybody's guess. But to even suggest that the sysadmins should say "oh, fuck it. It's the vendor's fault" is a bit like putting one's network in the hands of God... maybe it will be OK, and most likely it won't.
Re:Regardless (Score:5, Informative)
Windows patches and hotfixes are a whole world of pain. SP2 for NT4 erased filesystems. SP6 crippled people running Notes. Hotfixes regularly blow each other away. They're a *mess*, and a good Windows admin will be *very* cautious about applying either hotfixes or service packs for NT/W2K/XP because the QA on them seems to be so low, so often.
Full Disclosure analogy (Score:1)
It is about lighting a "fire" under a vendors ass.
Perhaps so Culp does not forget this point he should take the advice in another story and "tatoo it on his butt" if he needs to.
And not in invisible ink, btw.
IIS is an appropriate acronym. (Score:1)
It Isn't Secure.
How apropos.
biology/environment (Score:2)
So how does Microsoft survive? Is it a virus?
Schneier Understands Crypto (Score:1)
Schneier always mentions that you have to watch out for people motivations. In this case, he should point out that his company makes its living watching for bugs/hacking/vulnerabilities in the systems of the customers that it monitors. He usually does this, but I definitely see it as fodder for Culp to throw back in his face. If the bugs were hidden, Counterpane would have a lot harder time knowing what to look for.
I really liked the point about software companies being liable for the software they produce. The implication from his article was that a firewall manufacturer isn't not liable if a hacker breaks in because of shoddy code in their firewall. Is this true? Anyone know of (or have a subscription to one of those cool legal services) any legal cases that have proved or disproved this?
It seems pretty fundamental.
Rudy
Proof that Full Disclosure is the ONLY way to go (Score:1)
In the third case, the people there were informed about the attack and were able to stop it in time, because they had full disclosure of what was happening in the other cases.
Now, looking at these two security exploits, which do you think was the better solution, the passengers who were unaware of what was happening until their planes crashed into the World Trade Center buildings, or the ones who were informed and fought back?
Paul Robinson <Postmaster@paul.washington.dc.us [mailto]>
Full Disc. everywhere BUT the computer industry (Score:2, Insightful)
For example the auto-industry. If you buy a new/used car and it is a lemon or has massive faults that can cause serious damage the vendor is expected to state those faults [ftc.gov]
I have two children and ANYTIME there is even the slightest risk of problems with the products we have bought for them, the vendor says don't use it any more.
You would think that Microsoft would have learned from Firestone/Ford....
Software liability and disclosure (Score:3, Insightful)
Almost every piece of commercial software you install these days has something in the license like (taken from the Red Hat legalese):
"There is no warantee for the program, to the extent permitted by applicable law. Except when otherwise stated in writing by the copyright holders and/or other parties provide the program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warantees of merchantability and fitness for a particular purpose. The entire risk of as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair, or correction."
Now someone explain to me why, when software vendors disavow all responsibility for their products, they should be granted some special status with regards to information about those products' misbehavior.
Hit 'em where it hurts (Score:1)
We instead need to find a Lever that is appropriate for today economic climate: Money.
I say, make Vendors financially responsible for the damages incurred during an exploit. We've all seen the outrageous dollar amounts attached to some of the random e-mail worms that exploit Microsoft's Software. Since Vulnerabilities are Programming Mistakes, why not make the same laws that govern other flawed products applicable to Software?
Wasn't Napster held liable for damages done because of their Software Product and Services? Why shouldn't Microsoft be held accountable because of damage done by means of their Software Products and Services? Heck, that might even be something appropriate to tack on the Settlement Agreement by Microsoft's Bitch^H^H^H^H^H^H^H^Hthe DoJ.
I don't think you can get the attention of any corporation unless you hit them where it hurts: the profit margin ... just my $0.02
Disallow Liability Disclaimers (Score:2)
In the current model, even with full disclosure, the most they risk is sales loss due to bad PR, and to modernize the old saw, "nobody ever got fired for buying Microsoft".
subliminal messages (Score:2, Funny)
It's not just what he says; it's how he says it. For some reason, the above sentence makes me think of a particular vendor.
Vulnerabilities or Back Doors (Score:1)
I've pulled IE from my home M$-Windows systems (one for the games I cannot get on Linux and one for a system that captures music-keyboard MIDI data to a score, which is another thing that I cannot find for Linux), using IEradicator (http://www.98lite.net) and some registry tweaking, and I've got a couple of layers of firewall running, but I still want to know what holes are in those systems, my Linux boxes, and my Solaris system. I neither want my data stolen or corrupted, nor do I wish to contribute to damaging anyone else's system(s).
Disclosure (Score:1)
The script-kiddie issue is just one we must live with; A sysadmin can only get access to the same data as a script-kiddie can. If the sysadmin needs it, then with that right comes a responsibility to test and patch systems.
If non-disclosure is good for vendors and consumers, then *all* vendors would be pushing for non-disclosure - not just Microsoft. As it is, the *nix vendors are happy with the status quo, because they are reasonably happy with the quality of their software.
However, proof-of-concept code does not necessarily prove/disprove the presence of a threat. If the exploit addresses a particular subset of an overall fault, then just because the exploit fails does not mean that the fault has been fixed - see compiler optimisation "cheats" for example.
When the source is open, then the exploit can be more easily shown to be complete/incomplete - otherwise, the exploit either works/doesn't work - but that could imply a failing in the exploit code, or a partial workaround in the patch, which simply avoids the exploit.
I disagree with the author that there is no incentive for vendors to provide secure code - Secure Solaris being one example - but the customer must pay megabucks for such a promise, and compromise the customisability they expect.
In his essay, Culp compares the practice of publishing vulnerabilities to shouting "Fire" in a crowded movie theater. What he forgets is that there actually is a fire, the vulnerabilities exist regardless. Blaming the person who disclosed the vulnerability is like imprisoning the person who first saw the flames.
Nuff Said.
Thus guy Culp's name... (Score:2)
Since Mr. Culp is Microsoft's appoligist, might his title at MS be Mea, that would make his full title ther Mea Culpa?
Or, since they have found MS guilty of being a Monopoly, would that make this person in charge of culpablity for MS?
ttyl
Farrell (running, ducking and hinding...)
can someone explain (Score:2)
I'm not interested in arguments about open-source systems, or how vendors should be liable for bugs, etc...
I simply want to know why it makes sense to publicise the code for a vulnerability as opposed to saying "there a bug in this area, we're working on a patch". What are the benifits?
I wonder: should we send Osama Bin Laden precise instructions for making Anthrax, Small-Pox, or Nuclear Weapons?
Too many patches (Score:1)
That's their fault for not using Debian. [debian.org]
Great article (Score:1)
what better way to describe the "script kiddy" problem.
Aye, there's the rub! (Score:2)
> Since full disclosure has become the norm, the computer industry has transformed itself from a group of companies that ignores security and belittles vulnerabilities into one that fixes vulnerabilities as quickly as possible. A few companies are even going further, and taking security seriously enough to attempt to build quality software from the beginning: to fix vulnerabilities before the product is released.
And Microsoft doesn't like fixing problems, let alone building quality in from the start. Those activities don't add anything to their bottom line; it's a waste of resources.
Microsoft doesn't like the new norm, therefore it doesn't like full disclosure. (Where's the surprise?)
To say nothing of the bad PR that hits the world's presses twice a week when the latest MS-specific exploit shows up at the disclosure site.
missed implication (Score:1)
The arrogance of Microsoft in taking a non-disclosure line is amazing. Essentially they're saying that the vendor has a right to the information but the people who're actually responsible for the systems the faulty product is running on don't. Excuse me, but in what fucking universe does that crock of shit make sense? The vendor isn't *entitled* to non-disclosure; as the customer I *am* entitled to disclosure just as much as I'm entitled to know if the model of car I'm driving has a known brake line problem.
Screw this non-disclosure, delayed-disclosure, or whatever line of bull MS is selling. I don't give a rat's ass about the credibility or stock value of the company who sells a hackable product; all I care about is how I can secure my system until the hack is fixed, or if the product is so full of holes I should just toss it and migrate to something else. Neither MS nor anyone else gets to make this decision for me.
Max
Here is another excellent article (Score:1)
It is very well written and the arguments presented are logical. This is the type of rant that MS needs to hear, although they seem to be masters of burying their head in the sand.
The threat (Score:2)
The real threat is someone who goes looking for security holes, finds them, and quietly uses them to steal information or money. It's the people who are stealing credit card numbers, bank account info, and military information that are threats. Serious attackers will often work to obtain inside information, and may be willing to combine physical attacks with computer attacks.
Vulnerabilities left open but not publicized open doors for the real attackers. Non-disclosure shuts down only the more inept script kiddies.
See also Richard Frono's article (Score:2, Informative)
(also on The Register [theregister.co.uk]).
How Microsoft policy worked last week (Score:1, Insightful)
Companion piece in The Register (Score:1)
This message... (Score:1)
By disclosing any useful information within this message, one could determine my posting history, motivations, and style, from that extrapolate the sequences in my DNA base pairs, then feed my physical and mental state into a complex iterative model of the Universe.
This could be seen as paving the way for recovery of time machine plans from the future, allowing you to go back and assassinate Bill Gates before he could come up with this crap.
Besides the obvious problem, that being that Microsoft's software of unsurpassed quality will never be released, such an event would create a causative paradox in the Universe, the end result being total destruction of all matter and energy.
In short, all hail Gates and his mighty army of high-priced lawyers!
(Note for the sarcasm-impaired: the preceding message was just a joke; don't mod me down)
Reliability Possible (Score:1)
Bruce,
Your message is consistent, effective, and helpful. However, one remark you often repeat is being used to justify harmful practices, and even harmful legislation. It plays into the hands of Microsoft and those like them.
In your ZDnet article you wrote, "the sheer complexity of modern software and networks means that vulnerabilities, lots of vulnerabilities, are inevitable." Microsoft's Scott Culp had written, "all non-trivial software contains bugs." The difference between the two statements is probably too subtle for most of your readers. As you say, almost all software vendors do very shoddy work, and most large systems are riddled with holes. Still, the step from "almost all" to "all" is much larger than it might seem.
From Counterpane's business perspective, the distinction probably makes no difference; Counterpane must accept its customers' software deployment choices. From the standpoint of a judge or legislator, though, it makes all the difference in the world. If reliable software really cannot be written, then Microsoft and its ilk must be forgiven their sloppiness at the outset; it would be wrong to hold them to an impossible standard. If in fact reliable software can be written, then such ilk are negligent in failing to produce it.
This is not an academic point. It affects your argument, and Microsoft's. If a software system will always be full of holes no matter how many patches are applied, publicizing holes just makes it harder for network administrators to keep up. It is the availability of reliable alternatives that cinches the full disclosure argument: users can get off the patch treadmill by switching to software that's not buggy. The extra work done to ensure reliability pays off when users switch, or needn't. Full disclosure punishes the sloppy (and their customers) and rewards the careful (and their customers).
It doesn't take many examples of truly reliable software to make the point, in principle. How many bugs remain in Donald Knuth's TeX? In Dan Bernstein's qmail? These were not billion-dollar efforts.
Once it's demonstrated that reliability is possible, getting it becomes a matter of economics. Microsoft, rather than saying reliable software is impossible, is forced to admit instead (forty billion dollars in the bank notwithstanding) that they simply cannot afford to write reliable software, or that their customers don't want it, or, more plausibly, that they just can't be bothered to write any, customers be damned.
Instead of promoting a destructive fatalism about the software components we rely on, you would do better to say simply that current economic conditions lead most organizations to deploy systems known to be full of vulnerabilities. Leave open the possibility that slightly different circumstances would allow for a reliable infrastructure. Reliability is no substitute for effective response, but it just might be what it takes to make effective response possible.
Nathan Myers
ncm at cantrip dot org
Patching difficulty is not an excuse (Score:1)
From the article:
I do fault the sysadmins: It's our job to maintain systems as securely as we are able. It's part of the cost of doing business.
We should maintain continual pressure on the vendors to improve their initial software quality, to improve their security vulnerabilities especially, and to improve their patching experience to make it easier to apply secure patches with some degree of confidence (which would be an outflow of improving their software quality in the first place--the same processes apply to patches as to a full-fledged app).
However, we should never use a vendor's failings as an excuse for not maintaining due diligence on security matters.
A company's management makes a decision--rational or not--to use a system. Part of that decision includes total cost of ownership. If total cost of ownership outweighs the total benefit derived from a system, don't use the system.
Now, most of us aren't in a position to make a final decision on systems, so we must influence the decision by making sure TCO includes the cost of maintaining security patches.
Bruce Schneier to speak in Minneapolis (Score:2)
"The Natural Laws of Digital Content" on November 15 at 7:00 at the University of Minnesota Minneapolis campus.
The subject of the talk is related to the topic of this story - how legislation such as DMCA interact with computer security issues. So if you're interested in this topic and live near Minneapolis click the link above to find out details about this talk.
Also, we [faircopyright.org] hope to tape Bruce's talk and put up video and audio of the talk on our web site at a later date.
valid alternative to full disclosure (Score:2)
I think that in such a world, software quality would improve dramatically, and software manufacturers would be at least as motivated to fix bugs as they are in a world with full disclosure.
Look at this quote from Culp's piece... (Score:2, Insightful)
"Providing a recipe for exploiting a vulnerability doesn?t aid administrators in protecting their networks. In the vast majority of cases, the only way to protect against a security vulnerability is to apply a fix that changes the system behavior and eliminates the vulnerability; in other cases, systems can be protected through administrative procedures. But regardless of whether the remediation takes the form of a patch or a workaround, an administrator doesn't need to know how a vulnerability works in order to understand how to protect against it, any more than a person needs to know how to cause a headache in order to take an aspirin."
This is Microsoft's opinion in a nutshell: Don't worry about the details, we'll take care of you. That doesn't surprise me for end-users, but for administrators? When I see a bug announcement with a detailed example, such as the ftp_conntrack bug in iptables, it is tremendously advantageous to actually understand the bug and how to deal with it. In that case, several workarounds suggested themselves, because the bug only afected RELATED connections.
Now take the MS paradigm: I wait until they release a patch, or detailed instructions which I should follow by rote. Of course, I am affected by the vulnerability longer; furthermore, I get no transferable knowledge from the experience. Next time there's a similar bug, I just have to wait, again, instead of being able to invent a workaround.
Sure, it's _possible_ to implement a workaround when I don't understand the vulnerability, but I sure feel a lot better when I understand the problem AND the solution. I simply don't understand how this MS scheme (where everyone is an unenlightened end-user, waiting for cryptically-named patches which they don't understand) could appeal to any business OR home user. By assuming that even its administrators are unqualified to do manual reconfiguration by themselves, or even really understand what they're doing with the OS, MS has effectively crippled their fleet of administrators. And this, ultimately, is why the NT(2k/xp, whatever)platform is the huge, gaping security hole it is.
I simply can't believe the arrogance and stupidity of the statement above.
"...an administrator doesn't need to know how a vulnerability works in order to understand how to protect against it, any more than a person needs to know how to cause a headache in order to take an aspirin."
I think that speaks for itself.
Re:Errors.. (Score:1)
Re:Errors.. (Score:1, Offtopic)
He's. Contraction. [he is], [he] possessive.
Which is it? "he is written"? And don't say "He has", that's not a contraction!
Now let's discuss your dangling participle...:-P
Re:Errors.. (Score:1, Funny)
They re-did PowerPoint?!?! k-l33t man!
oh - wait - they just did a PowerPoint presentation.
Re:criticize MS all you want (Score:1)
MS get lots of attention, but in all fairness, there was plently of critisism when BIND started the closed mailing list.
Additionally, they are not really the same in scope. BIND may not release vulnerability info to the public, but they aren't trying to stop everyone else from doing it. Microsoft is.