Software Bugs: To Disclose or Not to Disclose October 3, 2005 Kenneth van Wyk http://www.esecurityplanet.com/views/article.php/3553196
It's the age-old battle of security: to disclose or not to disclose software defects. The proverbial pendulum of opinion has been swinging back and forth on this issue for decades, and it's not likely to stop any time soon. The issue reappeared just recently when an ISS employee was prohibited from speaking at a conference on the topic of a security vulnerability in Cisco's IOS operating system. Here's my take on it... First off, it's not a simple yes or no issue. There are different shades of gray here, folks. At the two ends of the extreme we have no disclosure and 'spontaneous disclosure'. Neither of these are even worthy of serious consideration in any practical sense, since neither produce any sort of positive results. The litmus test of positive results that I've always used over the years is this: Does publicizing the details of this vulnerability make the problem smaller or bigger? We're talking big picture now. It's been my experience that not releasing information on a vulnerability invariably results in a larger problem than the one we started with. This is primarily because the people who need to know about the vulnerability most -- the end users and system administrators -- aren't armed with the appropriate information to make informed decisions on when and how to update their systems. In my book, that is unconscionable. At the other extreme, it's also been my experience that spontaneous disclosure -- releasing everything about a vulnerability the moment or so that it's discovered -- also results in a larger problem than the one we started with. The end users and system administrators often don't have practical solutions or workarounds (for instance, turning off email is not an acceptable business solution in almost every case). Similarly, the product vendors are forced to slap together a quick patch that may or may not address the root cause (no pun intended) of the problem. We'll delve into this further in a moment... So, both of these options are non-starters. If we accept these arguments, then it becomes a question of how we release information and what information we release. That's where my opinion differs from that of a lot of the practitioners out there. There are a few published and ad hoc processes for responsible disclosure of vulnerability information. My biggest gripe with them is that they don't take into account the software engineering that needs to take place at the vendor level to appropriately address the problem. In particular, most call for a static, predetermined time period between notifying the product vendor and the public release of information about the vulnerability. That model is horribly flawed. Setting a Deadline My rationale is as follows. At the top-most level, software security defects fall into two general categories: design flaws and implementation bugs. It's the implementation bugs that we hear the most about in popular literature. They include buffer overflows, SQL insertion, cross-site scripting, and the like. The most common cause of these problems is inadequate filtering of user data inputs. Many, but not all, implementation bugs can be fixed quite simply and easily. A poorly constructed string manipulation function in C, for example, can be made secure in just a line or two of remedial coding. On the other hand, design flaws can be much more pernicious. The fix to a design flaw by its very definition requires the developer to change the application's design. A design change can have far-reaching ramifications. Think basic software engineering principles here. To responsibly make a security change to an application's design requires the same degree of engineering scrutiny, testing, etc., that goes into designing the application in the first place, lest even nastier flaws (and perhaps even implementation bugs) appear as a result. It all comes down to this... Some software defects can be fixed quickly and easily, while others can require great deals of engineering effort to be properly fixed. There is a broad spectrum of effort levels required to fix any particular vulnerability. So, you see, setting an arbitrary time period for disclosing a vulnerability is not responsible at all. Instead, the period of time should vary depending on the nature of the vulnerability itself. Forcing some time period into the process is like holding the proverbial gun to the head of the product vendor, and that can't possibly result in the sorts of patches we all want for our systems. Even if you work with a product vendor to negotiate an appropriate amount of time for disclosing a vulnerability, the next issue in disclosing responsibly is what information to disclose. Most CERT-like organizations have formats for vulnerability advisories that do a good job here. The most controversial topic here is how far to go in disclosing. For example, is it reasonable to disclose an example of how to exploit the vulnerability? Again, I look to my litmus test, and I err on the conservative side: It makes the overall problem bigger to disclose example exploit code. Now, I realize that a lot of you are hissing and spitting at me right now, and I can accept that criticism. My opinion is unchanged by it, however. There are good ways and bad ways of disclosing vulnerability information. If we all share the goal of having secure applications that have had their known defects fixed, then it's in our collective best interest to allow the product vendor the necessary time to properly engineer and test security patches. Otherwise, we're condemned to an existence of getting security patches that have been developed under duress, cause other problems, or just plain old don't work right. Come to think of it, that is a pretty accurate description of many of the patches that we see from all too many of our software product vendors, and that's no coincidence. Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense. You are a subscribed member of the infowarrior list. Visit www.infowarrior.org for list information or to unsubscribe. This message may be redistributed freely in its entirety. Any and all copyrights appearing in list messages are maintained by their respective owners.
