Internet Security Systems violated community standards and common sense with its surprise Apache bug announcement.
In the end, the computer security community must stand together to promote those things that are in everyone's interest.
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
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
In another Bugtraq
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
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.