Looking for Volunteer Rails Developers!
The Open Security Foundation is looking for a few good Ruby on Rails developers to help us on a volunteer basis in developing and enhancing osvdb.org, as well as datalossdb.org.
We need folks who are interested in security, with a background in Ruby on Rails development.
For helping on OSVDB, you really need to have a solid understanding in these areas:
- Single-table inheritance
Dataloss DB isn’t as complex. A volunteer needs only to be experienced with REST and have already worked on RoR projects, but also have knowledge and experience with SOLR to help with the learning curve!
Both projects require experience with Subversion, and decent written communication skills.
If you’re interested in helping out, we encourage you to email us at:
moderators[at]osvdb.org (for OSVDB work), or curators[at]datalossdb.org (for datalossdb.org work).
In your email, please send a quick and informal resume with links to Ruby on Rails work you’ve done in the past, or projects you’re currently working on.
It’s not a job… it’s an adventure (or a hobby, or just a way to do something important for the InfoSec community!)
The long and winding road…
… that leads to your door will never disappear…
Sorry about The Beatles lyrics, but the last couple of months have seemed like a rather long and winding road as far as posting new vulnerabilities is concerned. Many hours (days/weeks/months) of combined effort went into making OSVDB 2.0 a reality. When that finally happened, we were faced with another new challenge: clear out what appeared to be a huge backlog of vulnerabilities stacked up in what we refer to as “NDM”, or the New Data Mangler queue. Cliffs Notes: the NDM queue is a backend stash of vulnerabilities that haven’t yet been added to the front-end database; those entries generally need basic information added such as disclosure dates, external references, and titles that clearly reflect the nature and impact of a vulnerability. At the time OSVDB 2.0 was released, we were looking at a queue of over 1,000 entries in the main NDM queue that each needed at least a couple of minutes of attention.
I’m taking a few minutes away from the NDM queue to type this post. When I started typing, the NDM queue was sitting at 331. As of this sentence, it’s now at 325 as Jericho works on pushing more vulns to “new” status. That doesn’t include the new vulnerabilities that come into NDM on a daily basis, so the drop of 700 vulns is NET, not gross. On or about January 5, 2008, OSVDB’s database gathered its 40,000th vulnerability. In the last 52 days, over 2,200 vulnerabilities have been added to the database. We would like to thank everyone who has supported OSVDB by taking their time to add references, vendors, credits, and descriptions, but we have a little surprise…
There’s another 2,000 vulnerabilities or so to go until we can say we’re “caught up”. We also have a very large stash of CVE-listed vulnerabilities dating back to at least 2002 that require data entry and inclusion into the database. For now, we’re focusing on getting the most recent vulnerabilities into the database, but we will DEFINITELY need more help going forward. If you’re interested in being involved, please let us know; OSVDB is a COMMUNITY project and we would like to have more people involved to help improve data quality, data quantity, and security awareness as a whole. For any questions or comments, please mail us at firstname.lastname@example.org
back to NDM… down to 324… ;)
New Database Export Formats & OSVDB Personal Edition
We just introduced 3 new database export formats:
- MySQL (mysqldump)
The easiest of the three to download and dive into is SQLite, though the MySQL dumps take a close second. The CSV tarball also includes a SQL script to import the data into MySQL simply for reference. Perhaps someone can contribute a Postgresql CSV import script?
All of these are available at the database info page – along with an updated visual representation of the Schema. The old XML dumps are still there and continue to run, but the scripts used to process them are now officially deprecated. Simple reason being that they don’t work any longer, and given the above new methods of getting your hands on the data, the old scripts are obsolete anyways.
Also, as a sample of how one can utilize the new export formats, we’re releasing OSVDB Personal Edition. OSVDB Personal edition is a very small Ruby on Rails application that utilizes the SQLite database export to give you your own, albeit relatively feature-less, local OSVDB instance.
It’s quick and easy to setup (requires a few dependencies be installed, all documented in the README), and has been tested on Linux, Windows XP, Windows Vista, and Mac OS X Leopard. There are some minor issues running on Tiger, which are somewhat documented in the README.
OSVDB Personal Edition is not intended to really be a new offering by OSVDB, as aforementioned, it is primarily a way to showcase our new database exports. You can grab it from our tools section.
In less exciting news, the vendor dictionary has been rid of the annoying ajax popups, and the search engine has received some mild tweaking.
Ruby on Rails developers needed! Testers too!
We are looking for a few Ruby on Rails programmers to help us further the OSVDB project. The positions are volunteer, and we have little to offer outside of some interesting programming challenges, kudos, and satisfaction in helping to further a great resource for the community.
The requirements are that you have at least some experience with rails and subversion, as well as working with a team. If you’ve worked with STI, RESTful stuff, and all manner of XML parsing fun, that would be a plus.
We’re also looking for testers to help us hammer away at new code before pushing it live. The testing help is also volunteer, and requires very little time commitment. Essentially, when the developers need something tested, we’ll shoot out an email to the testing volunteers to hammer away at something specific.
If either of these are of interest, send an email to email@example.com and let us know which role you’re interested in.
OSVDB API and Enhanced Cross-referencing
We are pleased to announce the OSVDB API beta.
Integration and cross-referencing with OSVDB just got a lot easier via the new application programming interface (API), which can provide multiple result formats to fit various needs. Queries can be run against any number of correlation factors, including CVE ID, Microsoft Bulletin ID, Bugtraq ID, and a host of other common reference points. The API is also under constant development, particularly during beta, and suggestions for improvements are quickly and easily implemented by the OSVDB development team.
Some technical details about the API include:
- It is a RESTful interface to the OSVDB database
- It returns your choice of XML or CSV
- Allows OSVDB ID correlation to a growing list of other references and integrators products
- And importantly, it is free – though donations are appreciated.
To begin using the API, first, login or create an account, then visit the API overview for general information, or skip right to the API Documentation to get started. During beta and perhaps beyond, accounts are limited to 100 queries per day. To request a greater allotment of daily queries, fill out the Integration request form.
In other news, we have done some significant mapping work over the last month. We have broken out certain references into a new category called “Tools & Filters”. A good example of how this section works is OSVDB ID 40229. We then worked to map:
- Over 9,500 OSVDB ID’s to Nessus nasls
- Over 1,000 OSVDB ID’s to Snort filter ID’s
- Over 400 OSVDB ID’s to Nikto scans
We are also in the process of working with other vendors and products to map out more tools. If you have an open source or commercial security product, and you reference vulnerabilities, contact moderators for information on how we can include your filters/rules in our vulnerability listings.
The Price of Restricting Vulnerability Publications
The Price of Restricting Vulnerability Publications by Jennifer Stisa Granick
There are calls from some quarters to restrict the publication of information about security vulnerabilities in an effort to limit the number of people with the knowledge and ability to attack computer systems. Scientists in other fields have considered similar proposals and rejected them, or adopted only narrow, voluntary restrictions. As in other fields of science, there is a real danger that publication restrictions will inhibit the advancement of the state of the art in computer security. Proponents of disclosure restrictions argue that computer security information is different from other scientific research because it is often expressed in the form of functioning software code. Code has a dual nature, as both speech and tool. While researchers readily understand the information expressed in code, code enables many more people to do harm more readily than with the non-functional information typical of most research publications. Yet, there are strong reasons to reject the argument that code is different, and that restrictions are therefore good policy. Code¹s functionality may help security as much as it hurts it and the open distribution of functional code has valuable effects for consumers, including the ability to pressure vendors for more secure products and to counteract monopolistic practices.
Bugs and Money
Jennifer Granick has a good article up on Wired titled “Bug Bounties Exterminate Holes,” which talks about some of the issues raised in a panel discussion at CanSec last week. She makes some good points about commercialization of vulnerability research–pros and cons, risks and rewards, etc.
It’s well worth reading the whole article, but one small bit caught my eye…
I have advised two businesses that had plans to auction vulnerabilities to the highest bidder on eBay. (After talking with me, each decided not to take the risk.)
This is pretty disappointing. I would love an environment where software vendors are forced to pony-up cash to researchers if they want bug details, and are forced into a competitive market against “value-add” services (iDefense, ZDI, etc.), and even criminals. Some may see this as a form of blackmail, but I think it will shed some much-needed light on how vendors feel about security, and how much money they are really willing to spend to keep their customers safe. Already we see a non-profit organization (Mozilla) willing to pay $500 for the information, and multi-billion dollar companies unwilling to pay anything.
I realize there are many legal and ethical problems with auctioning vulnerabilities that need to be wrestled with (including problems with eBay), but would it really be worse than it is right now?