LINUX SECURITY --- October 24, 2000 Published by ITworld.com, the IT problem-solving network http://www.itworld.com/newsletters ********************************************************************* HIGHLIGHTS * To disclose or not to disclose, that is the unanswerable question ********************************************************************* How to Handle a Software Vulnerability by Rick Johnson Over the years, an unwritten code of honor has developed within the white hat community. Code hackers who find a security vulnerability or exploit within a piece of software typically will contact the author and allow a patch to be written before announcing the discovery. This topic has inspired great debate amongst the security minded over the years. Recently the discussion has taken a strange turn. The Internet's cornerstone of security advisements, CERT, announced a change in their long-standing disclosure policy regarding vulnerability information. In the past, CERT would not issue an advisory until the software vendor released an applicable patch. According to CERT's new policy, "All vulnerabilities reported will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors. Extenuating circumstances, such as active exploitation, threats of an especially serious (or trivial) nature or situations that require changes to an established standard may result in earlier or later disclosure." For complete details, please visit http://www.cert.org/faq/vuldisclosurepolicy.html. Is this a wise policy? Therein lies the debate. On one side stands those who think vulnerabilities should be publicly released as soon as they are found. This does provide software users all of the relevant information as soon as possible and, in theory, they will then be able to decide whether to keep using it or find a replacement. However, even though the end user has the information, they may not have the knowledge to fix the problem. Since the vendor most likely received the information at the same time, it may be days before a patch is released. Of course, script kiddies around the world now have the information and the knowlege to use the exploit. Obviously, this is not a wise choice. On the other side stands have those who would prefer vulnerability information not be released until the vendor releases a patch. On the surface, this appears to make sense. Unfortunately, a great deal of software vendors will not act on these reports without public pressure. Hence, many affected systems remain vulnerable for an extended period of time. Again, not a wise choice. There appears to be no acceptable solution other than requiring all software to be bug proof. Reality dismisses that idea before its inception. CERT has chosen a comfortable middle ground. I hope that their policy will allow a diligent vendor the time needed to release the proper patches. Now if we could just find a way to make users install them. RESOURCES CERT stepping up disclosures of security holes http://www.itworld.com/jitw/linsec_nl/cma/ett_article_frame/0,,1_2958.html Microsoft tells users to fix 'serious' IIS security hole Flaw allows intruders to read and execute files on IIS-based Web servers http://www.itworld.com/jitw/linsec_nlcma/ett_article_frame/0,,1_3127.html Linux firewall survey, Part 2: Commercial firewall products Worth the price: FireWall-1, Phoenix Adaptive Firewall, Gateway Guardian, and XSentry http://www.itworld.com/jlw/linsec_nl/lw-2000-10/lw-10-fwproducts2.html About the author ---------------- Rick Johnson is currently the Manager of Security Services for FusionStorm, a remote managed services company. When not writing, he heads the development team for PMFirewall, an Ipchains Firewall and Masquerading Configuration Utility for Linux. Rick can be contacted via email at rick@pointman.org or on the web at http://www.pointman.org.
<<attachment: winmail.dat>>