Jonathan, You touch on a couple of topics which are worthy of exploring further. First, lets talk about the nature of risk. It is not black and white. It is a continuum, very difficult to measure exactly but can usually be estimated. In the security profession you quickly learn that not only can you not eliminate risk, but in many cases it doesn't even make sense to try. Your job is to manage and reduce risk as cost-effectively as possible. I agree that full disclosure serves a purpose. However, I disagree that _immediate_ disclosure is the best solution because it imposes too much risk on the end-users (the victims). In your example, you had the option of disabling SSH until a patch was available. Others probably could not pursue that course of action as the opportunity cost would have been too high. That is, there are many enterprises in this world that absolutely depend on SSH to function efficiently. Many probably didn't disable SSH even when they knew there was an unpatched vulnerability. Were they lazy? Were they just stupid? I doubt it. They most likely performed a risk assessment even if it was made unconsciously. That is, they estimated the potential cost to their organizations of leaving SSH active until a patch was available against the lost revenue and/or increased cost of doing business they would incur if they pulled SSH until a patch was available. You did the same thing. However, in your case the risk of leaving SSH active was probably much higher than the cost of not having it. What immediate disclosure does is immediately increases the total risk incurred by the users of the vulnerable software until a patch becomes available. Contrast this against what is currently generally accepted practice: notify the vendor; give them a reasonable amount of time to fix the immediate problem; give them a reasonable amount of time to audit for any similar problems; give them a reasonable amount of time to verify that they haven't introduced any other problems in the course of fixing the current one; post your advisory after either a patch is available or a reasonable time has expired. This practice greatly reduces the risk to the end users (remember they ARE the victims here). The vendor is still "punished", maybe not as harshly as you would prefer, but these announcements do still take their toll. The key here is that no unnecessary collateral damage is imposed upon the victims in the interest of making sure that the "vendors get what is coming to them"... Now lets talk about the LAZY humans and software vendors. They aren't any more lazy than you are. They are arguably quite efficient (as a group) with their limited resources however. Perfectly secure software has a development cost. In fact, it is a VERY high development cost. This cost would have to be passed on to the customers and now we get back into our discussion of risk and opportunity cost. If a vendor provided a commercial version of SSH that they have made flawless for $10,000-100,000 a copy, would you buy it? (Why so much? The cost of development increases and must be passed on to the customer base. As the cost goes up the potential customer base shrinks and therefore, the cost burden per remaining customer also must increase. A very non-linear relationship! Granted, this greatly simplifies a very complex subject in its own right, but it is accurate enough for this discussion) I doubt that you would. It wouldn't be very cost effective of you. Your personal risk in dealing with the occasional SSH bug that occurs has an amortized cost far less than $10,000 (the minimum opportunity cost of being more secure in this scenario). You still use the publicly available SSH even after its history of bugs don't you. Even when clearly presented with evidence that the software has a history flaws (and likely has other as yet undiscovered ones), you still do not choose a very significantly more secure alternative of removing your system from the Internet. Does that make you lazy, stupid, or smart/efficient/practical? Why don't the commercial vendors of SSH produce a guaranteed flawless product? Is it because they are full of lazy programmers or greedy executives? I do not think so. I would argue that the marketplace doesn't currently support it. Customers do want more secure products, but they just are not willing to pay enough extra for it to support the development costs. Paul -----Original Message----- From: Jonathan Rockway [mailto:jrockw2@xxxxxxx] Sent: Wednesday, December 22, 2004 1:06 AM To: bugtraq@xxxxxxxxxxxxxxxxx Subject: Re: DJB's students release 44 *nix software vulnerability advisories On 21 Dec 2004, at 3:22 PM, laffer1 wrote: > As for the other comments in this thread about telling the vendor > early, I personally feel it helps users if the vendor has a few days > to look at the hole and devise a patch BEFORE everyone on the planet > knows about it. You punish users of software in addition to vendors. > All software has a security problem of one kind or another, and its > silly to think that a perfect application will every be written. Why are users using insecure software? Or rather, why do users accept the fact that their software may be insecure? Besides, full disclosure helps the users too. I remember a few years ago when the major SSH remote hole was found. I read about it on slashdot between classes. Since there was no patch yet, but there was an exploit, I ssh'd into my home machine and turned off ssh. Even if there wasn't an exploit, I wasn't going to leave a vulnerable service up and running. By the time I got home, sshd was patched, and I installed that patch. If nobody had disclosed the threat to me, I could have been compromised. But, because I was notified, I was able to take preventative measures. The sooner someone told me about the problem, the sooner I was able to protect myself from the threat. Full disclosure is important because vendors will drag their feet if they're the only ones who know about it. Imagine you are a student and have a paper due "whenever". When are you going to write the paper? Today? No, you'll do it later. After all, nothing bad happens if you don't do it, and not doing it is much easier than doing it. Humans and software vendors are LAZY. If there's no reason to do something, they won't do it. Full disclosure forces the issue and puts everything out in the open. No "it'll be ready in 90 days" stalling. It will be ready NOW or users will look to more secure alternatives. They will make the first move and choose a program that doesn't have security problems to begin with. This is better for everyone (well, except people with financial interest in selling crappy software. that doesn't particularly upset me, though.) I do have more sympathy for open source developers. They are not trying to profit from the security of their software, so I think they deserve a little leeway. BUT, fixes are usually contributed by outside experts. The experts can't just guess "Oh, I bet Person A of the NASM project needs help with security problems. I'll send him an email and ask if he needs help." They need to know about the vulnerability before they can attempt to fix it. If they're reading a full disclosure mailing list, they'll know about the problem. Then they can code up a fix, email it to the author, and bang, it's fixed. It all starts with full disclosure, though. (Without full disclosure, the author of the software would be on his own to fix it. With full disclosure, someone more experienced can help him out. That's a Good Thing and is what makes the Open Source movement work.) Full disclosure makes the Internet more secure. It forces vendors to fix their broken software, and it forces users to update their broken software. Less broken-ness is good for everybody. If you disagree, you are probably writing broken software and are afraid of what your users will do to you when they find out about it. Good luck with that, and remember: don't shoot the messenger. If you wrote the buggy code, you have only yourself to blame. Regards, -- Jonathan Rockway <jrockw2@xxxxxxx>
