Tag Archives: Changelog

OSVDB 2009 Q4 Changelog

I always mean to post changes more frequently, but apathy and other tasks seem to win the day. Here is a brief list of OSVDB change highlights over the past few months.




  • New menu system (top and left nav)
  • Twitter feed more actively used for project updates
  • Twitter feed displays on front page
  • ‘About’ page is updated, expect more static pages to be updated to better reflect project status soon
  • CVSSv2 scoring support added, including:
  • CVSS scoring history (historically track NVD, OSVDB and other sources)
  • Anyone can submit scores for entries without CVE/NVD (over 13,000)
  • Updating CVSS scores for entries without are worth .25 points for now, to encourage mangling
  • Moderation system in place for submitted CVSS scores
  • Creditee system overhaul (https://blog.osvdb.org/2009/11/21/creditee-system-overhauled)
  • “Vulnerabilities in OSVDB disclosed by type by quarter” graphs added to front page
  • More fixes to continue support for IE6. Don’t expect this to last!

OSVDB Content Update

I always mean to post these more often, but I find myself bogged down in adding entries and putting off blog updates. Quite a few little blurbs and thoughts related to OSVDB content.


  • I love vendors who maintain good changelogs. A good changelog has many attributes: version release with date, links to bugs/forums when appropriate, clear but concise language, categorize entries such as ‘security’ or ‘feature’, etc. Further, the changelog should be easy to find and stay updated. Rhinosoft (they maintain many other products as well) is a company that serves as a great example of this.
  • On the flip side, I despise vendors with bad changelogs. One example is IBM who keeps these ridiculously large changelogs, mostly in CAPS with overly vague wording for many issues. As an example, check out this 1.4 meg changelog and try to pick out all the security issues.

Searching OSVDB – Our search engine got an overhaul a while back. While better overall, there are still a few bugs in it. Our dev is going to be available part time come Oct 1, so hopefully they will be knocked out in short order. Until then:

  • If search results seem wrong, try using all lower case or exact case. Known bug that some searches seem to work with one, and not the other.
  • We use keywords when appropriate. This can be useful for example, if you want to see all vulnerabilities in Zoller’s recent multi-browser disclosure. Search All Text for “one bug to rule them all”.
  • Using references as a search field can be valuable. If you want to see all vulnerabilities in PHP (the core language), you can’t title search because of so many PHP applications littering the results. Instead, reference search “php.net” for a concise list.
  • If you search for two terms, it will show results with both words. Searching with three terms will show results with any two words. Known bug! Until fixed, you can work around this by using “+one +two +three” search syntax, with a plus leading each keyword.
  • OSVDB is also tracking vulnerabilities in electronic voting machines. While still in progress, we have scoured the excellent technical reports from the State of California on Premier Election Solutions (formerly Diebold) and have made good progress on Hart InterCivic. To see all of these vulnerabilities, search All Text for “Electronic Voting Machine”.

Historical Content

  • I recently finished combing through the old Zardoz mail list archives. All of the vulnerabilities from that list, operated by Neil Gorsuch between 1989 and 1991, are now in the database. For those interested in historical vulnerabilities, reference search “securitydigest.org/zardoz” to see them. 63 vulnerabilities, only 7 of which have CVE references. Unfortunately, the mail list archive is not complete. If anyone has digests 126, 128, 206, 214, 305, 306, 308, 309, 310 or 314, please send them in!
  • Similar to Zardoz, but already in OSVDB for over a year, you can reference search “securitydigest.org/unix” for the old Unix Security Mailing List disclosed vulnerabilities. There is some overlap with Zardoz here, but it should yield 57 results, 6 of which have a CVE reference.
  • For crypto geeks, you can title search “algorithm” to get a good list of cryptographic algorithms, and when they were demonstrated to be sufficiently weak or completely broken. These go back to 1977 and the New Data Seal (NDS) Algorithm.

Random Notes

  • I recently noticed another case of a vendor threatening mail list archives. Looking at the Neohapsis archive or the lists.grok.org.uk archive of a recent report on Inquira vulnerabilities, you can see each has redacted information. Mail list archives provide a valuable service and typically get little to no benefit for doing so. Despite that, it would be nice if they would post the actual legal threat letter when this occurs.
  • The OSVDB vendor dictionary has been around for a while, but needs additional work. It is the first step in not only providing vendor security contact information, but building a framework for “vendor confidence”. This will eventually allow researchers to determine how cooperative a vendor is and if it is worth their time to responsibly disclose a vulnerability. As it stands, the Vendor Dictionary is primitive and needs to evolve quickly. One example of a problem we ran into, is a researcher submitted a case where they had a ‘bad dealing’ with a given vendor and it is included in the notes. The vendor contacted us, quite surprised to see it, and asked if we agreed with it. I responded that no, that was far from our own dealing with the vendor and that they had been great to work with in disclosing vulnerabilities, providing additional details or answering general questions. Reading our entry on the vendor doesn’t reflect that, and it should. Hopefully in the coming months, with a part time developer, we can begin to address this.
  • When sanitizing takes its toll. BID 28219 has a link to an exploit that appears to have aggressively sanitized characters. Or did the researcher actually send that in? VDBs need to be mindful of this and add a note if they are displaying the submission as is.

Why I’m So Behind

Another night of working on OSVDB, mainly focusing on vulnerability import and creating our entries to cover issues. Most nights end with between 25 and 50 new entries and a feeling of accomplishment. Well, other manglers can see the accomplishment if they check the back end, and that gives a little positive reinforcement. On really big days I just spam the status line to Jake and Sullo and demand instant gratification and the promise of booze to dull the pain.

Anyway, tonight was productive but no one but me and Speedbump will realize. I can thank IBM and a set of ridiculously large changelogs full of mind-numbing poorly written bug reports and excessive (apparent) duplication of entries. It started out with a simple bugtraq post about some vulnerabilities in IBM WebSphere Application Server. First off, I find it quite amusing that people are now taking credit for merely posting vulnerability information culled from another source.

Provided and/or discovered by:
Reported by the vendor

Reported by SnoB

If this type of activity deserved merit, VDBs like Secunia, CVE and OSVDB would be virtual gods of vulnerability disclosure. Second, he lists seven issues from a changelog that contains hundreds. If you go dig through the changelogs like the one for the Fix List for WebSphere Application Server Version 5.1.1, you may find more of interest. While browsing them, I noticed a fairly insignificant but ironic characteristic of the way IBM handles these disclosures. If you want to read the list of over five hundred entries and only pick out the security related ones, you can! Skim the list for any P##### number that doesn’t hyper-link to another document. 95% of the time, these are security related. So while IBM is not providing additional details about these issues (security through obscurity), they are making it easier to pick out which entries are of interest.

Oh yes, back to the exciting night life. After checking the latest list of changes as well as digging into some past fix lists, I ended up with around 75 more vulnerabilities, most of which are not in our database (or others). This list I extracted has some dupes in it, meaning the same issue affected multiple products or version lines. However, it is quite curious to see the same vulnerability patched half a dozen times over two years across many versions. Is IBM reintroducing the same vulnerability back into the code over and over? Or are they following the Oracle method of mitigation and not looking at the bigger picture and fixing similar vulnerabilities in the same code? Anyway, since I know I won’t get an answer to that, consider that it would take you twenty or more hours to read and digest a handful of these fix lists, and in doing so, you would likely find fifty or more vulnerabilities above and beyond what I found. The amount of information is overwhelming to say the least.