[This was originally published on the OSVDB blog.]
I had the need to search for Apache vulnerabilities today for the pesky day job. One word, one search and four hours later I realized just how bad our Apache entries were. Enter headache #1. Unfortunately, the rest of the VDBs were no better. What did I want a concise list of?
- Apache web server vulnerabilities
- Apache Tomcat vulnerabilities
Seems straight forward, and the second search is relatively easy to get at any VDB as “Apache Tomcat” is a consistently used name for the product and distinct enough not to catch other products. So why isn’t the first? Many moons ago, Apache was just “Apache” and everyone knew it was the web server. Eventually Apache branched out and currently maintain an incredible amount of projects. The old “Apache” we all know is really “Apache HTTP Server” which VDBs don’t consistently use, especially the older ones. This is understandable because when CVE added an Apache vulnerability in 1999, that was all there was. These days, just using “Apache” to describe any of their projects is overly vague and irresponsible. Thus, four hours later i’d like to think that OSVDB’s entries are a lot better off for many reasons, that being the first and most simple.
Searching OSVDB by title for “Apache HTTP Server” will now list all vulnerabilities related to the classic web server. One thing you will notice is the different in naming convention for modules. Enter headache #2! Apache modules are not created equal. According to the Apache documentation, module status is labeled according to one of four values:
- Base – modules that are compiled and loaded into the server by default
- Extension – modules that are not normally compiled by default, but must be selected during compilation/installation
- Experimental – modules that are available as part of the apache kit; not necessarily supported
- External – modules that are not included with the base Apache distribution; not supported by Apache
Modules like modinclude and modimap are ‘base’ modules and are part of the Apache web server for most installations. Vulnerabilities in these modules will impact most Apache users. Modules like mod_rewrite are extension modules and must be specifically selected during the configure/make process.
Modules like modperl are .. what? Hello Headache #3. If you check the modperl homepage, you don’t see the easy to spot designation if it is ‘base’ vs ‘extension’, even though it is part of the Apache project. This is more understandable with modssl since it’s an extension and maintained on a non-Apache web page. Apache module authors: please make this clear! Before you fire up your e-mail client to send me obnoxious mails, consider that these are “some” of the supported modules Apache offers, and there are 443 more modules that aren’t supported but definitely useful to many folks. What about moddigest_apple and others? Not fun for those who are tasked with tracking vulnerabilities.
As a result of all this, OSVDB is now using consistent titles to help distinguish all of the above. Here are a few guidelines to help better understand it, and we hope that other VDBs will follow suit to assist their users.
- “Apache HTTP Server” is used for the Apache web server (httpd).
- If the module is ‘base’, ‘extension’ or ‘experimental’, meaning it is part of the Apache distribution, we use “Apache HTTP Server mod_whatever”
- If the module is ‘external’, meaning it is not part of the Apache distribution, we use “mod_whatever for Apache HTTP Server”.
This will help our users more easily distinguish if the vulnerability affects them, assist in searches with more concise results and generally make me feel better about the VDB world.