Security Woes, PR Shouldnt Mix

Security Woes, PR Shouldnt Mix

Written By
Jim Rapoza
Jim Rapoza
Jun 19, 2002
2 minute read
eWeek content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Earlier this week, the mainly pristine security record of Apache took a hit when a major vulnerability was found in many versions of the very popular Web server.

This was a serious problem, as big as any of the recent holes that have plagued Microsofts Internet Information Services Web server, making it possible for attackers to potentially run code on affected systems.

Luckily, the Apache Foundation has reacted quickly and a patched version is now available on their site (the patched version appears to be working fine on our now-patched Apache servers here in eWeek Labs).

However, one of the most troublesome aspects of this problem wasnt that it existed (every bit of code has potential security pitfalls); it was how the problem was disclosed.

Ive consistently defended the rights of researchers and security firms to make vulnerabilities known to the public. However, I also believe that certain procedures should be followed before making a vulnerability known to the general public.

One of the best definitions of the procedures that researchers and security firms should follow is the RFPolicy from security researcher Rain Forest Puppy. One of the key elements here is that once the person who found the problem agrees to cooperate with the code maintainer, then time should be given to resolve the problem–“provided you cooperate with the researcher and keep them in the loop, they should provide you with whatever time necessary to resolve the ISSUE (within fair reason),” the RFPolicy states.

However, it appears there was another factor in the decision of Internet Security Systems, the firm that found the problem, would disclose it. Namely, competition. When ISS found out that a joint announcement from the Apache Foundation and security firm Next Generation Security Software Ltd. would be released on CERT, ISS decided on an early release in order to get the public recognition.

Of course, this left all Apache users at the mercy of attackers, something that wouldnt have happened if ISS had waited a day or so for the patched Apache versions to become available. ISS did provide a workaround–which, according to the Apache Foundation, didnt really fix the problem.

Of course, ISS will probably say that beating the competition had nothing to do with its release and that it was just protecting customers. If that were the case, why didnt ISS do what security companies do all the time and give its customers the information without alerting the entire Internet?

There are reasons that researchers sometimes need to release vulnerability information, especially if the maker of the software is stonewalling them and trying to pretend the problem doesnt exist. But doing this to get a PR edge over competition isnt a valid reason.

Should security researchers disclose vulnerability information without a fix? Let me know at jim_rapoza@ziffdavis.com.

eWeek Logo

eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site's focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.