[This was originally published on the OSVDB blog.]
I’ve spent the last few hours working on the OSVDB database, specifically working on making sure that we had entries that correspond with two vendors and their security issues. After an hour or two of digging through the Hitachi advisories, I questioned why we only had ~ 20 entries when there were closer to 80 advisories. Ends up many of them cover vulnerabilities that impact a wide variety of platforms such as Microsoft vulns, OpenSSL or other more commonly deployed cross-platform packages. Unfortunately, Hitachi’s security team didn’t have the common sense to include links to the original advisories OR links to the CVE numbers in many cases, making my job extremely difficult. And yes, I leave feedback on vendor advisory/KB pages “was this helpful” boxes. And yes, we make an effort to include their advisories on the related entries.
Next, I moved to BEA and the WebLogic mess. Historically, I like Macromedia/BEA as they have been open and honest about vulnerabilities for many years. They don’t seem to try to hide the fact their software has bugs, and they release advisories with detailed patch information. While the actual vulnerability information may be a bit vague, I fully understand the fact that they will release the most basic information and appreciate they do so to protect customers. I think that it is extremely important in this day and age to do so. That said… I am making BEA my example for this post. Apologies, but you deserve it (was re: please, learn from this rant!)
Like many vendors, BEA maintains a security advisory page. Release date, advisory number, title, products affected. This gives more summary information than most, and on first impression seems very helpful and thorough. However, to the anal retentive and compulsive VDB maintainer, it is a nightmare. Go ahead, look at it again.. what’s wrong with it?
First, look at their advisory IDs. Second, look at the links to their advisories and the resulting URL you would get if you clicked:
http://dev2dev.bea.com/pub/advisory/138 – BEA05-87.00
http://dev2dev.bea.com/pub/advisory/139 – BEA05-80.02
http://dev2dev.bea.com/pub/advisory/140 – BEA05-85.00
http://dev2dev.bea.com/pub/advisory/141 – BEA05-86.00
http://dev2dev.bea.com/pub/advisory/142 – BEA05-88.00
http://dev2dev.bea.com/pub/advisory/143 – BEA05-89.00
A nice logical progression in advisory numbers… 138, 139, 140, yet the BEA advisories go 05-87, 05-80, 05-85. Why don’t these correspond? Ok ok, minor annoyance I know, but when you are trying to create a timeline to help you verify you have every advisory in a database, it sucks. Now, for the real sin! Look at the HREF links from the list of advisories, to the URLs (remembering that the URLs are like the ones quoted above).
2005-08-15 | BEA05-61.01 | A patch is available to prevent Denial of Service attack
2005-05-24 | BEA05-82.00 | Denial of Service attack
Yet these link to 134 and 132. Where is 133? Almost three months between these, and they skipped 133? No, they didn’t… follow the link to one of those two, but manually change the URL and voila, advisory ‘133’ is there (do this in other parts, and there isn’t an advisory at all, just a big gap..). Why doesn’t BEA include that link on their page? Scroll up through the advisories, and look at the links as you mouse over. Notice the other missing advisories? 123, 124, 130, 133 … where are you?
BEA (and countless other companies), you are making life hell on your customers that pay attention to detail (and us anal retentive folk that run VDBs). Please, use some basic logic and common sense when ordering or numbering such advisories. If you skip numbers, put in a brief note explaining that it is intentional. It shouldn’t be too difficult to have one or two people that coordinate the disclosure efforts, and they should not have problems that may cause this kind of mess. If you don’t explain these gaps, your paying customers are going to want to know what you may be hiding.