[This was originally published on the OSVDB blog.]
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.
Changelogs
- 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.