O O Ø O O O O
Full Disclosure
The argument that vendors shouldn’t be such sissies, and start fully describing their bugs.
“You should reserve public exposure for the rare cases that the vendor ignores your warning. As it is, you have probably induced several enterprising crackers to attempt to exploit this vulnerability in the few hours it will take us to re-spin all the software, and thus you are the one who would be liable for any mis-use of this bug.”
I saw this comment in BugTraq yesterday, and I have to admit, it bothered me.
The basic issue here is one of Full Disclosure. Should information about security vulnerabilities (including exploits) be made available to the public immediately (a la BugTraq), or should the issue be resolved with all affected vendors first (a la CERT).
Issue 1: Full disclosure of security-related information can inflict more damage than good. You are showing people how to break into systems.
A clever attacker does not need full disclosure in order to penetrate a system. A simple description of the problem is almost always enough. By giving as much information about a potential problem as possible, system administrators can make intelligent decisions about whether they are affected, what the severity of the problem is, and what action they should take. After all, which would you prefer:
Some 3COM Switches may have back-door passwords
or
My 3COM CoreBuilder 2500 has a default user/password: debug/synnet. I did a dump of the EEPROM image for a SuperStack II switch and found a default tech/tech account. Test these accounts against your hardware to see if you are affected.
The second case may give away more information, but it also allows the system administrator to take immediate action.
Issue 2: Vendors should be allowed time to fix a problem before details are made available.
This is a thorny one. Certainly, vendors should be made aware of problems in their products immediately. Unfortunately, not all vendors are prompt about addressing security-related issues in their products, and any time spent waiting for a vendor fix is time that somebody’s systems are vulnerable to the problem. If there is an error to be made here, I would err on the side of caution. That is, I would err on the side of Full Disclosure.
Contact the Vendor, yes, but if you don’t receive a response in a relatively short amount of time, disclose the problem. And if you do receive a patch for the issue, disclose the problem then. The devil you know is infinitely easier to deal with than the devil you don’t.
Issue 3: Liability
Liability is an annoying problem. It is very easy to make a statement like “You posted an exploit, you are liable for its misuse.” Unfortunately, this statement is both untrue, and aggravating.
The vast majority of security-related bugs in software have been discovered before. The buffer overflow is not a new thing, yet vendors still insist on writing code that blindly strcpy’s user data into fixed-size buffers. Back doors were a bad idea long before they were immortalized in the movie War Games (in 1983), yet vendors still insist on putting them in their products. Theo de Raadt and the OpenBSD project have been carefully reviewing and fixing security holes in software for years, and still have to complain that authors keep introducing the same dumb security holes in their software all the time. If we all stopped writing buffer overflows, cookie-cutter buffer overflow exploits would no longer be an issue. If we paid more attention to our past errors, we might not be seeing so many problems with our code.
Vendors need to fix the root causes of their problems, and take responsibility upon themselves for ridiculous security holes. We all need to learn from our mistakes. Full disclosure is an important tool in identifying these mistakes and the ways we can avoid them. It can help make our work more secure. Let’s all use it.
Kjell Wooding
Friday, May 15, 1998
Addendum
Just before my article was posted (but after our publishing deadline) the author that made the original comment posted a followup. In fairness, I have reposted it here:
Yesterday, I made a posting that was out of line and non-constructive. I’m going to try to rectify that.
I’m not against people reporting security holes (or posting information on the specifics of the vulnerability, up to and including the method of the attack). If I implied that, it was my error.
I have been informed that this list exists to serve users who have become disenchanted with CERT and “the establishment,” and hence the readership values immediate disclosure of all security-related problems, and I have no complaint about that, either.
My problem is that the posting to the list was not also sent to Cygnus. Instead, we satisfied another 64 download requests in the time between the posting to BUGTRAQ and notification by a BUGTRAQ reader to Cygnus, some 17 hours after the original posting was made.
Within 30 minutes of (delayed) notification, we verified the problem, shut down our distribution, and began to fix the problem. The problem was fixed 2 hours later, and we spent 6 hours last night and another 4 this morning hours verifying the fix for the platforms we support. We expect to have the fixed software available for ftp within the next few hours. Our start->finish response is expected to be about 19 hours. The reason it didn’t happen faster: we were notified just before the end of our business day.
Had we been notified concurrently with the BUGTRAQ posting, we’d have fixed the problem yesterday, and we would not have distributed buggy software to 64 additional people.
Modulo relativity, I realize that time applies to all of us equally, and that notifying Cygnus before the public cannot “undo” damage that’s been done. OTOH, by not notifying Cygnus promptly, we continued to do damage without knowledge of the fact. That is what really upset me yesterday.
Peace (I hope),
The BugTraq View
When it is advisable to post to the list without contacting the vendor:
- When you cannot find a contact within the vendor to make a report.
- When the vendor will not fix the vulnerability.
- When the product is no longer actively supported.
- When you believe the vulnerability to be actively xploited and not informing the community will cause more harm than good.
All this being said, we rather have people report vulnerabilities to the list and not the vendor, whatever their reasons may be, than having them keep the information to themselves.
– Aleph One, BugTraq Moderator
Kjell Wooding
Friday, May 15, 1998