Digg this story   Add to del.icio.us  
Irresponsible Disclosure
Jon Lasser, 2002-06-26

Internet Security Systems violated community standards and common sense with its surprise Apache bug announcement.

The Apache security hole reported by ISS last week ends one of the most remarkable streaks in computer security. The last major Apache security holes were reported in January 1998. Four and a half years without a serious vulnerability in so widely used an application is an incredible record, one for which the Apache team should be commended.

Unfortunately, the circumstances under which the vulnerability was reported leave a bad taste in my mouth and the mouths of many other proponents of full disclosure.

ISS emailed Apache about the bug for the first time at 9:44 a.m.on June 17th. Then they went public with it that very afternoon, according to a mailing list post by ISS's Chris Klaus. The advisory hit Bugtraq at 3:57 p.m.

Apparently, ISS believes that a time of less than eight hours is sufficient not only for the Apache Foundation to verify the bug and provide an official patch, but for dozens of third-party vendors shipping Apache -- a group that includes Red Hat, IBM, and SGI, among many others -- to develop, test, and release patches for their binary distributions.

Given that these global organizations must perform quality control on their software, and that the Netcraft survey for May shows that more than half of all Web sites run on Apache, it seems entirely inconceivable that a coordinated response to the holes discovered by ISS could have developed in less than one workday.

In another Bugtraq post defending the rapid release of the security advisory, Mr. Klaus claims that because ISS released a patch for the exploit along with their advisory, there was no need for a quiet period. This view is naïve, at best; vulnerabilities in any software with the reach of Apache need to be handled more carefully.

Earlier this year @stake's Chris Wysopal and MITRE's Steven Christey submitted, then withdrew, a draft Internet standard for responsible security disclosure, as part of an security company pact that ISS actually signed up for. Maybe it's time to revive the proposal.

"This is exactly why we've tried to promote a standardized disclosure process," Jody Patilla, program director for @stake, told me. "There needs to be more than a gentleman's agreement that we're all going to abide by the same rules."

I am a strong proponent of full disclosure, as regular readers of this column know. However, if a hole is not actively being exploited, it's best to give developers a chance to respond. This is especially true when the package is as dominant as Apache. The thirty to forty-five days that ISS claims they typically provide to companies regarding security holes should have been observed, and would have been adequate, in this case.

Open-Source's Social Contract
Ultimately, it turned out that the Apache hole might have been discovered and exploited earlier, but ISS did not know this at the time they posted their advisory to Bugtraq. Even if the exploit was being used in the wild, it was not widely known, and no "script kiddie" exploit existed at the time.

The ire shown by many Bugtraq readers and system administrators shows that ISS acted in violation of community standards of behavior. Mr. Klaus claims that ISS acted with the best of intentions, and I'm inclined to believe him -- but that simply makes their clearly premature announcement an act of colossal ignorance rather than one of malice.

"With open-source it's a little more difficult, but there are still responsible parties for all of these packages. When you have established open-source groups like the Apache group, I think there's no reason not to treat them as you would treat a commercial vendor," says Patilla.

I'm inclined to agree. Furthermore, It seems to me that there's an implied contract in the open-source world regarding vulnerability disclosure: if the maintainer of a package is responsive to the needs of the community, work through that individual or group. This is the same guide to behavior that prevents excessive forking of open-source packages, and it works.

When a developer patches a software package, to add a feature or fix a bug, he or she should submit that fix to the maintainer of the code. If the developer chooses not to accept the patch, for whatever reason, or is entirely unresponsive, it is perfectly reasonable to propagate the patch without the developer's support. But if the developer does prove responsive, the patch need not be released publicly.

In that case, the official developer must give credit to those who originally discovered the presence of the bug. A security researcher depends on that credit to protect and enhance his or her reputation, and relies on that word of mouth for work. The package maintainer must respect and promote those who help to debug the package, just as the debuggers must respect and promote the authority of the pack maintainers.

In the end, the computer security community must stand together to promote those things that are in everyone's interest, so that everybody is treated fairly. As with most security issues, it's not a technical problem but a people problem.


SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
    Digg this story   Add to del.icio.us  
Comments Mode:
Irresponsible Disclosure 2002-06-26
Anonymous (1 replies)
Irresponsible Disclosure 2002-06-28
Anonymous
Irresponsible Disclosure 2002-06-26
joe90@hushmail.com
Irresponsible Disclosure 2002-06-27
Please please please get a new UNIX writer! (7 replies)
Are you working for ISS ? 2002-06-27
nimp
Irresponsible Disclosure 2002-06-27
Anonymous
Irresponsible Disclosure 2002-06-27
Anonymous
Irresponsible Disclosure 2002-06-29
Tired of loud mouth open source freaks (1 replies)
Irresponsible Disclosure 2002-06-29
Anonymous
Irresponsible Disclosure 2002-06-27
Anonymous
The shoe is on the other foot 2002-06-27
Anonymous (10 replies)
The shoe is on the other foot 2002-06-27
Anonymous
The shoe is on the other foot 2002-06-28
Anonymous
The shoe is on the other foot 2002-06-28
Anonymous
The shoe is on the other foot 2002-06-29
Anonymous
The shoe is on the other foot 2002-06-29
Anonymous
The shoe is on the other foot 2002-06-29
pseudoAnonymous
Penalties 2002-06-27
Anonymous
Irresponsible Disclosure 2002-06-28
System Engineer in UK
Irresponsible Disclosure 2002-06-28
Anonymous
Irresponsible Disclosure -- CYA 2002-06-28
Anonymous
hehehe ! apachi is next victim 2002-06-29
ICMP_Z@yahoo.com (1 replies)
hehehe ! apachi is next victim 2002-07-01
Anonymous
what i think about ms... 2002-07-03
Lysergsäurediethylamid


 

Privacy Statement
Copyright 2010, SecurityFocus