Posted by jericho
Wed, 18 Jun 2008 23:32:25 GMT
Stephen Christey of CVE posted asking a question about VDBs and the inclusion of coffee makers. Yes, you read that correctly, vulnerabilities are being found in coffee makers that are network accessible. Don’t be surprised, we all knew the day was coming when every household appliance would become IP aware.
Before you laugh and spew your own coffee all over the keyboard, consider that the vulnerabilities are legitimate in the sense that a remote attacker can manipulate how the device performs and possibly do physical damage to the unit. This is really no different than SCADA devices such as air conditioners that are IP aware.
Some replies (like mine) were a bit more serious suggesting this type of vulnerability is definitely worth inclusion in OSVDB. If we can’t draw the line between coffee makers, air conditioners and other SCADA devices today, we will be able to in a year or years from now? At some point, the blur between computing device and household appliance will be too hard to distinguish. Rather than waste too much time arguing that line, why not track these few vulnerabilities now that might be a bit primitive, but will surely show historic value if nothing else.
Other replies were a bit less serious but fun, suggesting that making weak (or no) coffee would lead to disgruntled code writers that produce poor code filled with more vulnerabilities. Either way, count on us to include vulnerabilities in your favorite IP aware devices, kitchen, computing or otherwise, to this database.
Posted in General Vulnerability Info | 1 comment
Posted by jkouns
Fri, 16 May 2008 02:41:24 GMT
Layered Technologies has provided hosting for the OSVDB production and development servers since October 2007 and continues to support the project. The new servers have been a critical contributing factor to the success and deployment of OSVDB 2.0. In fact, OSVDB 2.0 and the new services that we are now offering have been more resource intensive than we originally thought and we must upgrade.
On Friday, May 16th at 9pm EST we will be taking the OSVDB server offline. The outage should be minimal and service will be restored as soon as possible.
We would like to take a moment to thank Jeremy Suo-Anttila for his assistance and support of the OSVDB project. If you are interested in high quality but affordable hosting with very responsive support we recommend that you contact Layered Technologies.
Posted in General Vulnerability Info | no comments
Posted by jericho
Sun, 02 Mar 2008 06:39:48 GMT
Often amused by smaller software projects and their inability to clearly define a) the project name or b) who owns/operates the project. While working on a vulnerability today I ran across IAPR Commerce that seems to have several names depending on where you read the main page:
- IAPR COMMENCE Conference Management System
- IAPR Conference and Meeting Management
- IAPR COMMENCE System
- IAPR Commence
Despite these names, the SourceForge project page just shows “Commence” for download. Why can’t vendors make it more simple?
Posted in General Vulnerability Info | no comments
Posted by jericho
Mon, 13 Aug 2007 13:27:38 GMT
Due to a recent German law being passed, Phenoelit and now Stephen Esser’s Month of PHP Bugs has been removed.
Posted in General Vulnerability Info | 2 comments
Posted by jkouns
Sun, 29 Jul 2007 19:46:42 GMT
Once again many OSVDB members will be in Vegas for Blackhat and Defcon. We are planning a dinner and several small meetings to discuss the OSVDB project and future plans. If you are interested then please get in touch with one of the moderators so that we can trade contact information.
See you in Vegas!
Posted in General Vulnerability Info | no comments
Posted by jericho
Mon, 23 Jul 2007 12:34:10 GMT
I should have started a series of these posts long ago. One of the more frustrating parts of most VDBs is the lack of a helpful search function. Searching for some products (SharePoint) is easy enough, as the name is distinct and not likely to find many matches. If you happen to know the script affected (logout.php), that too can make the search fast and painless. However, what if you want to list all vulnerabilities in PHP?
CVE: searching for “php.net” yields 0 matches, while searching for “php” gets 2896
BID: search by vendor, PHP
ISS: advanced search, “php.net” will find most, but also include non PHP vulnerabilities
SecurityTracker: search “php.net” will find some, but a world of additional threads/advisories
Secunia: search “php.net”, pick a PHP vulnerability, click the software link, click vendor link, click the 6 links below corresponding to the major versions
If OSVDB had a complete data set, you could search fairly easily off the vendor name due to our vendor dictionary and listing associated products. Until then, one tip is to search references for “php.net” to pull up a list of all PHP native vulnerabilities. This won’t work for most vendors, but for the bigger vendors we’re trying to standardize our entries and references to facilitate easier searches.
If you know the specific GUID (3d742890-397c-11cf-9bf1-00805f88cb72) related to an advisory, or some other odd number or unique identifier, try searching the reference for it. This also goes for advisory identification numbers. Again, the data set is far from complete but we’re trying!
Many years ago I opened a ticket to create a new feature that allowed one to search for vulnerabilities by associated port. Curious what vulnerabilities are related to TCP port 1234 or UDP port 5432? No problem! Until we can get more developers on board and knock out some of these projects, search reference for “tcp port 1234” or “udp port 5432”.
Hopefully, more search tips to come.
Posted in General Vulnerability Info | 2 comments
Posted by jericho
Thu, 24 May 2007 02:56:06 GMT
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.
Posted in General Vulnerability Info, OSVDB News | no comments
Posted by jericho
Tue, 01 May 2007 17:32:11 GMT
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.
Posted in General Vulnerability Info | no comments
Posted by jericho
Mon, 09 Apr 2007 20:15:16 GMT
I previously blogged about the Month of PHP Bugs [MOPB], an effort lead by Stefan Esser and the Hardened PHP Project to raise awareness about vulnerabilities in the PHP language. The month has come and passed and of course I have to wonder about a few things.
The project ended up releasing 45 vulnerabilities over 31 days, many of them remotely exploitable. For anyone that was under the delusion that PHP was “pretty secure”, think again. Not only were some remote, many were methods for bypassing the native protection methods PHP offers like open_basedir or issues with various functions designed to filter bad input.
These “Month of X Bugs” always get a press blitz before it happens, but we rarely see the same news outlets cover the same thing a month later. It’s nice to see the results of the project, the number and type of vulnerabilities as well as any insights (see comments on previous blog post) the developers had.
The PHP project thankfully responded to many of these vulnerabilities already. PHP 5.2.1 and 4.4.5 fix a lot of security issues. Oh wait, that was released two weeks before the MOPB. Where is the next big release that fixes the unpatched issues?
All in all, a very impressive effort. Esser and the Hardened PHP Project have certainly raised the bar for the “Month of X Bugs” projects.
Posted in Vulnerability Disclosure, General Vulnerability Info | 3 comments
Posted by jericho
Mon, 15 Jan 2007 23:38:31 GMT
http://rixstep.com/2/20070104,00.shtml
A Month of Rixstep Bugs
It’s a win-win proposition.
Starting now and for the duration of January 2007 Rixstep will be holding a ‘Month of Rixstep Bugs’ campaign: find a bug in any Rixstep software product and win a prize.
It’s not a win-win proposition, it is a lame gimmick. After the month of apple bugs, week of (cancelled) oracle bugs, and the month of linux kernel bugs, Rixstep wants in on the bandwagon. Few small problems:
- They posted this announcement on the 4th, not even giving a full month.
- They didn’t post this to Bugtraq, Full-Disclosure or any other security list/resource I monitor.
- Rixstep doesn’t have the saturation that Linux, Apple or Oracle do. It is considerably easier to test those products and platforms versus Rixstep, who many of us have never heard of, let alone seen deployed.
If you want to play with the big boys Rixstep, man up and put some of your products up on your site and post the challenge to Bugtraq and Full-Disclosure.
Posted in General Vulnerability Info | 2 comments
