Microsoft's Internet Information Server is not the only Web server product that has vulnerabilities the vendor doesn't want to acknowledge. Apache 1.3.x for OpenBSD systems has an exploitable vulnerability that the Apache Software Foundation adamantly claimed was un-exploitable. Leave it up to the collective Internet intelligence to discover ways of doing the improbable and even some of the impossible.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The exploit, known as Apache-scalp.c enables remote crackers to access a command shell on any unpatched system running Apache 1.3.x on OpenBSD. The creator of the exploit, Gobbles Security, claims that this exploit could be easily ported against Apache versions for Sun Solaris, Linux and FreeBSD. Gobbles Security released the exploit only after repeatedly hearing that there was no exploitable vulnerability. A patch to correct this problem is available for just about every Apache platform. So, if you use Apache, it's time to patch a new hole.
What concerns me about this issue is just how difficult it is, even with the open source communities, to get developers and vendors to admit to security vulnerabilities, especially before an exploit is available in the wild. You would think that in today's security-conscious environment that any hint of a security vulnerability, especially on a popular and widely used product, would at least be taken seriously. With efforts to squelch or restrict public reporting of vulnerabilities for weeks or months, the lag between discovery and resolution can only become longer. If vendors are not motivated to resolve security problems until there are active media-hyped attacks occurring, then we as consumers will be getting an even shorter stick as the motivational element in this equation is silenced (i.e. prevention of public reporting of vulnerabilities).
Granting vendors a few weeks to create solutions to discovered problems and withholding public announcement of vulnerabilities until a patch is available sounds great, in an ideal world. Unfortunately, public disclosure seems to be the last remaining factor the consumer community can use to motivate vendors to resolve serious security issues in a timely manner. I think granting vendors a few days to verify and acknowledge vulnerabilities is a good thing. But I don't agree with the policy employed by many vendors: remaining completely silent or denying vulnerabilities for weeks, only then to reverse their stance once a patch is available.
James Michael Stewart is a researcher and writer for Lanwrights, Inc.