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.
It was bound to happen, now we get to see a Month of Search Engine Bugs. It would be nice if this effort included some bugs with meat rather than relatively obscure cross-site scripting issues.
The time has come for announcement of my new project – Month of Search Engines Bugs. This project will be in the next month. So June is a month of bugs in search engines. Purpose of this Month of Bugs is a demonstration of real state with security in search engines, which are the most popular sites in Internet. To let users of search engines and web community as a whole to understand all risks, which search engines bring to them. And also to draw attention of search engines~R owners to security issues of their sites. During the month everyday will be publish vulnerabilities in most popular search engines of the world. Cross-Site Scripting vulnerabilities in particular. Everyday will be publish vulnerabilities in different engines (minimum one publication at a time, but there will be bonus publications also).
Several of us working on VDBs have debated over the years how best to handle vulnerabilities that aren’t necessarily remote or local. Issues like image or archive handling vulnerabilities, where the program processing a malformed file is prone to an overflow, traversal or denial of service. While one may argue they are ‘remote’ in the sense that if I e-mail you the file, the attack is definitely remote in a sense. But, if the malformed file is loaded via a floppy disk, the attack certainly isn’t ‘local’ or ‘requires physical’ access necessarily. So we need something that covers the grey area between vectors. A while back Steven Christey at CVE began using “context-dependent attacker” to describe such vulnerabilities. OSVDB tried to come up with another term for this but after some time, we couldn’t. So, from here on out, you will start noticing the use of “context-dependent attacker” in our vulnerability descriptions more frequently, and eventually when the classification scheme is overhauled it will appear there too.
I saw this article the other day, IBM Scolds TippingPoint Over Hacking Contest and figured now what? But I decided it would be an interesting read.
A couple quick blurbs from the article:
IBM’s ISS division has torn into rival TippingPoint for sponsoring the hacking contest that led to the disclosure of a QuickTime vulnerability in Apple’s Safari browser. “IBM Internet Security Systems agrees with Gartner’s assessment that “public vulnerability research and ‘hacking contests’ are risky endeavors, and can run contrary to responsible disclosure practices.” It is for this reason that IBM ISS strongly adheres to its well-established responsible disclosure guidelines.”
Once I read the article it was then that I realized…. that it really wasn’t IBM, but ISS (who IBM purchased recently) that was scolding TippingPoint for sponsoring this contest. Immediately I thought about all the drama that went on when ISS disclosed their Apache Chunked Encoding Overflow back in 2002.
http://lwn.net/Articles/2756/ It all looks like a fairly normal response to security problems in the free software community, until you look a little more closely. It turns out that the Apache group was already aware of the problem and was working on a fix. The Computer Emergency Response Team (CERT) also was already involved. It also turns out that the ISS patch does not completely fix the problem. ISS, in its hurry to publicise the vulnerability, had not checked with either CERT or the Apache Software Foundation.
Does anyone remember all of this?
ISS took quite a bit of criticism for this disclosure and responded publicly to clean up any confusion and misunderstanding.
The very last portion of this posting is what I find real interesting:
ISS has made these decisions based on our mission to provide the best security to our customers and being a trusted security advisor.
For me personally.. It is kind of funny that disclosure almost always seems to come back to the argument of… we did it for the greater good… we did it for the benefit of others… we did it for the right reasons…
But you on the other hand…
Yet another “Month of..” bug campaign. This time, the Month of ActiveX Bugs (MoAxB) will focus on vulnerable ActiveX controls. Do a quick title search for “activex” and you will see a healthy history of vulnerabilities related to ActiveX controls. There is already a debate on the Full-Disclosure list regarding if this will be a month of annoying Denial of Service issues, or something more severe.