Slashdot Mirror
On The Costs of Full Security Disclosure
sasha328 writes "I found reference to this email on the LWN.NET site which was sent to the SecurityFocus mailing list. It asks a very valid question about how much you can disclose before malicious virii can be possible."
So, since releasing a security patch is equivalent to giving the blackhats full disclosure, no software should ever be patched again. Instead it should be understood that anytime anyone finds a security hole, they need to be quiet forever.
-f
www.blackant.net
Arguments against full disclosure are like arguments against sex education. Sure, there is this thing called 'sex', but we aren't going to tell you how to do it, or how to protect yourself. The whining about eEye overlooks one important aspect: CodeRed was not written by a script-kiddie. It may have been deployed by a script-kiddie, but it definitely was not written by one.
Let's say that eEye just released an advisory that said there was an overflow in the processing of default.ida. No more information than that. It would not take a skilled hacker very long to find the buffer overflow, and then exploit it. It doesn't matter if eEye says little or everything. The skilled hackers are going to find the hole themselves.
I believe the current system works as well as it can and should. When somebody finds a bug, they usually report it to the company, let them play with it for a week or so, work up a patch or workaround, and then it is posted publically on Bugtraq or some such list. Then somebody might write a proof-of-concept or an exploit, but will leave one part intentionally broken here or there so only people that can read the code and understand what is going on can fix it and use it. Bugtraq keeps companies accountable for their products security. Without it, there would definitely not be the same diligence at most companies responding to security concerns.
If you are going to teach sex, don't just say 'save it for marriage'; teach about condoms so people aren't caught with their pants down.
It was not till exploits started being written, and even further after there were some major epidemics, that unix admins and programmers tightened up on security. (sendmail? ftpd? bind? sheesh!)
Did Microsoft learn anything from these previous incidents? Yes, but very little. The greater cost of cleaning up Microsoft software reflects the widespread use of it by relatively clueless lusrs. But this widespread use means that "total cost" gets spread across a bunch more people. Was the disruption disproportionate to the laxity that Windows sys admins and Microsoft programmers had showed immediately prior to this incident? No, it was a bargain. And trust me, the cost of Code Red cleanup is a bigger bargain if it means that people will wake up to the importance of security in the future.
Right now in the wake of the dot-com collapse, an outbreak of Code Red means we can't get our email for a day or something. But when we are truly dependent on the net in the future it is imperative that we are ready and history shows us that we would not be without a few swift kicks in the pants like this. As I mentioned in another post, I don't think Richard Smith is sophisticated enough to be a leader on issues like this.
If the only action taken is to warn Microsoft, someone will discover the problem elsewhere, eventually. In the meantime, Microsoft is unlikely to take the complaint seriously - after all, the damage is only "theoretical", right? Now, it's a fact that there are a lot of inattentive, lazy sysadmins out there, many of whom are running IIS, and that's why they haven't all applied the patch yet - but at least with this in the news, it's harder for them to avoid it. How many would bother to apply the patch if there weren't any obvious benefit to doing so? Many might choose not to disturb a working installation.
Personally, I think that the only software that can ever hope to be secure in the real world is built like a tank. Use a language or library that makes it impossible to have buffer overflows; assign permissions to everything and never give out more than you need to; etc. But in an environment where exploits are only theoretical and only announced to the entity responsible for fixing them, you have to admit that companies like Microsoft will be very slow to fix them.
I metamoderate all Redundant and Offtopic moderations as Unfair.
Why is slashdot giving wind to this troll?
This guy is woefully misinformed, and completely stupid.
Anyone who is subscribed to Bugtraq knows that eEye has already responded to him, and the bottom line is that Code Red is not based (in any small part) on the eEye security bulletin.
This proves that the guy is completely wrong.. because Code Red wasn't based on the eEye bulletin, that means that the "black hats" already knew about the vulnerability.
Like scientists, security professionals rely on an existing body of work. If the only people who had access to this body was the vendors, it would slow down the white hats, making the entire situation worse, not better.
Please do not feed this troll.
...instead of a tap on the shoulder. Some companies need some "convincing" to make the necessary changes in a timely manner. Microsoft is definitely one those companies.
Unrepentant bullshit. Microsoft is very good at getting fixes out. Some bug-hunters expect a 2 hour turnaround time on their reports before "forcing MS to fix this by going public". Eeye even says that MS was quick in putting out a patch to fix the hole. The vast majority of bug hunters that actually take the time to work WITH Microsoft say that MS is quick in getting patches developed and in the hands of administrators, where they aren't applied (but that's a different story). Where's the sledgehammer? Can you support your claim with any evidence of any kind, or is this merely Yet Another Case of Uninformed Microsoft Bashing?
I thought the patch was already available when Code Red started spreading. Sorry, but whyle delaying the full disclosure can slow down the virus writers a little, it's not going to make lazy sysadmins apply patches to their servers any faster.
Personally if I found a security bug I'd do this......
1. If it was free software I would make a patch for it, then mail the patch and a full description of the problem to the makers of the product and several other security minded websites so that people would know that they had a problem and have the patch to fix it.
2. If it was closed source propriatory software I would give the company a 5 day head start (even if it was MS) by telling them privately first, then if they hadn't posted a patch yet (which IMO would be irresponsible or inept of them) I would post full details of the problem (and if it was MS maybe even code to exploit it) to force the company to move it's ass and distribute a patch.
Would I keep it a secret? NO. Why not? Simply because if I did, anyone else who came acrossed it could use it to their own advantage and hurt others. Why would I not simply inform the creator of proprietory software of the flaw and no pubicly post it afterwards? Because they can't be trusted. (not period) I have a feeling that they would simply ignore the problem until the average person became aware of it simply because they wouldn't want to waste the money correcting something that isn't well know. They would wait for the next BIG update to fix it which would leave the people ignorant of the problem vulnerable. By giving them 5 days I give them a chance to do the right thing with no pressure, then I release it to twist their arm into doing the right thing, if they can't figure out how to fix it.....tough shit they should've made it open if they can't handle their own software. If they release a patch before 5 days will I still release info and (possibly) code to exploit it? YES!!! Why? Because it is a sad fact that people will not install the patch until it is well known that they need it (take code red for example). By releasing an exploit sure I open the people who haven't patched yet up to abuse, but I also make the problem more known and force lazy sysadmins to get off their asses and get patched, in the end everyone is patched (except the stupid) and less damage has been done than would have before.
My philosophy is "If I can find it, others can find it" and I feel that letting the few people that find it run rampant with it is irresponsible and will cause more damge than bringing attention to the problem which may possibly let a few script kiddies do a small amount of damage rather than let an expert use an unknown method to safely exploit others for years.
Bottom Line? Security through Obscurity is ridiculous and does not work.
"
Microsoft deserves a head start, but that's it. If holes are kept to MS and the people that find them, it's only a matter of time before a Black Hat figures it out. Releasing the details puts pressure on the companies to fix the damn thing. Without that pressure, MS would feel little to no pressure to fix what they screwed up in the first place. You wouldn't be doing anyone but MS a favor by withholding this info. The lesson to be lerned is that if you son't want ot lose money from downtime and reboots, don't use Microsoft on your servers. Certainly don't depend on it.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
My only problem with this is that Microsoft lacks the motivation to fix the hole if no one else knows what it is.
Sure, people can point out there "some hole" exists. But unless the details are made public, Microsoft (or whoever)isn't motivated to fix it, and no one can check up after them to see if it has been fixed. We have to take their word for it. That would make me very nervous.
I wouldn't be against a "grace period" where the vendor is told of the hole so that a patch can be ready when it is announced, but it would need a time limit on it to keep it from being delayed forever.
--Ty
Vendors all around view a vulnerability that has been publically exposed as a much higher priority than those that have not been exposed. Over and over again, history has shown that a vendor will try to cover up a vulnerability if it is not exposed, to avoid bad publicity. (No, this is not specific to Microsoft, all vendors hate bad publicity). If an exploit is publically available for a particular vulnerability, it also changes the method in which the vendor advertises the patch, thus increasing the people who know about it and install the patch.
Full disclosure provides many useful functions, including the ability to test for vulnerabilities in their own systems. It gives them the abliity to verify that the system has been properly secured after a work-around has been implemented.
Partial disclosure, which is often suggested, is no different htan full disclosure, except it may give the admins a false sense of security. With partial disclosure, the existence of a bug is disclosed to the public - but the details are not. Sad enough, once the cat is out of the bag, it's only a day or two before someone else can figure out the exploit. Once the vendor releases a patch, it is trivial to do binary diffs on the provided updates and figure out the details of creating the exploit. In fact there are tools that help to automate this already in existence today.
The sad thing about code red is this: Patches have been available for quit a while now. Yet systems are still getting hit. The widespread affect of Code Red is the ONLY thing that will get the admins who never patch their systems to potentially pay attention to whats going on.
Full Disclosure is not the problem. If one person has found the vulnerabilities, there are generally more who have found them and are actively exploiting it already. To think otherwise is to seriously underestimate the cracker community.
--
Twivel
...instead of a tap on the shoulder. Some companies need some "convincing" to make the necessary changes in a timely manner. Microsoft is definitely one those companies.
Simple example, how many people use time functions in C without realizeing they are dealing with a very limited function which croaks in about 35 plus years. Use one of those functions to calculate a date beyond the range and who knows what you get for data. This bogus data then gets pushed into another function which is not checking because only valid data should come back from a built in function...
In many ways we get tripped up using code/languages which were designed under past limitations (8, 16, and 32 bit). The libraries need some cleaning/correcting, and code in general needs some serious error checking. Error checking along the lines of, "what happens when procedure X receives the impossible?"
In a place beyond time and space, in a land far better than this, look for me there...
There's also a series of articles on ntbugtraq talking about this issue. Russ Cooper is a huge proponent of what he calls 'Responsible Disclosure', whereby basically a mailing list is created which only has subscribers from people in the industry. Namely vendors of the security products, and of the OS and other tools.
This is the process that is used in the Virus community today, and it's been working well.
One of the points Russ made was that eEye could have discussed this issue on the mailing list before issuing a press release. In addition to feedback having been given by Microsoft, there would have been peer review. Additional information would have resulted, clarifications on impact and so forth.
Then a final press release could have went out, giving eEye full credit for finding the issue, but providing a wealth of useful information to the end-user/admin type folks.
Russ also raised a point about eEye's motivation. Why do they insist on not only full disclosure, but also releasing exploit code? Again he raises a good point, and I think it's quite clear.
eEye is in business to sell a product which supposedly protects you against these types of attacks before they happen. So it is in there best interests that an attack is quickly released and spreads rapidly, thus generating mass hysteria. Only with such hysteria can they generate traffic to their site and obtain orders for their product.
Unfortunately as code red has shown us lately security is a major player that people tend not to add into their budget or network configuration.
If operating systems came default everything turned off upon install we wouldn't have issues of this magnitude. Or perhaps if patches were properly applied in a timely manner.
I believe that the general public should be known of the security hole, in detail. Your network administrator/security group should be on the ball and fixing it when it's made public. If not you'll never know when a daemon, program etc needs to be patched or upgraded.
-maz
<happiness>beer</happiness>
I'm sorry, but I would really prefer to have the information that a certain lock installed on my frontdoor can be picked just by staring at it really hard, so I can go out and fix it or replace it.
If all I had to go one was "somethings wrong with the door" what the hell are we supposed to do about it?
Sure other criminals might now about it now. But I've already fixed the problem, or I have a contingency shotgun in place, etc.
Sure - Melissa et al. For years people have been bitching about the security of executing email attachments in Microsoft Outlook, and the amount of control over the machine that executed attachments have (no sandbox). The initial response from Microsoft was "that's a feature, not a bug", and even though there have been some steps in the right direction, the problem still exists and still breaks out into an epidemic from time-to-time.
I suppose that you could argue that clicking on attachments is more social engineering, but on the other hand Microsoft products are specifically sold as "easy to use". If it's so easy to use, why do users still fall prey to simplistic social attacks?
I'll admit that full disclosure hasn't even helped in this case, though - Microsoft and the whole world has known about the problem for a long time and it's still with us.
My heart bleeds for them - "we have so many security exploits that we can't even take the time to figure out which of them are real". Hint: do it right the first time, and then hire yourself some crackers to do this poking and prodding for holes that until now has been reserved mostly for the black hat community. I don't have much pity for Microsoft's inability to fix their security problems - they dug themselves into that hole by valuing time-to-market, embracing-and-extending, and pseudo-usability more highly than security and actual functionality.
Your right to not believe: Americans United for Separation of Church and