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@uic.edu>
