Mail List Archives 101 (or Why SF Hates VDBs)

[This was originally published to the OSVDB blog.]

Running a mail list archive is a straight forward task. Collect, organize and make mail list posts available via the web. You can see such archives at seclists.org or the Neohapsis arhive. Most folks that use archives like this have their favorites for various reasons. Speed, the lists they archive, or the organization usually. Most archives use a system where the URL to the post is logical and somewhat informative. Looking at the URL to the latest Bugtraq post archived at Neohapsis:
http://archives.neohapsis.com/archives/bugtraq/2005-10/0259.html
. We see the mail list name, the year and month, and a unique number for the post. Bugtraq, 2005, October, 259th post. Simple and easy!

SecurityFocus maintains an archive of the mail lists they run. Until a couple months ago, they used a scheme that wasn’t very informative. A sample URL http://www.securityfocus.com/archive/1/245152 shows it doesn’t help us discern anything about the post. Annoying, but oh well, most people could live with it. A month or two ago, SecurityFocus decided to revamp their system which would also impact their entire archive. They made assurances that the changes would be transparent and that old URLs would work. As I predicted to one SF employee, it didn’t work out so smooth, and many of the old URLs did not translate properly. At first he doubted me, then asked for examples. After providing half a dozen he saw that it wasn’t a fluke and that something had gone wrong. Unfortunately, whoever he shared that information with didn’t act on it. What is more annoying, and more damning, is that SF implemented a new scheme that is just as bad as the old one. Look at an example of their new scheme:
http://www.securityfocus.com/archive/1/414100/30/0/threaded
. This URL doesn’t tell us anything about the mail list or post either.

Why does this matter? There are hundreds of Nessus plugins that reference these old URLs, and in some cases only reference mail list posts, via the SecurityFocus archive. Clicking these now leads to .. no information. There are also countless CVE entries that reference the old URL scheme. If you want to see the original point of disclosure, you are forced to visit another database (that competes with SecurityFocus) such as ISS X-Force or OSVDB to see a valid link, as they choose to reference mail list archives that are more friendly to users.

In short, if you maintain a security product or database, please do not reference SecurityFocus or any other archive that uses an obscured scheme, or has intentions of changing their scheme.

Vulnerability Purchasing

[This was originally published on the OSVDB blog.]

Several years ago, iDefense started purchasing vulnerabilities from freelance researchers, and created its Vulnerability Contributor Program. Find a vulnerability, disclose it to iDefense under mutual NDA, and they would act as a mediator between you and the vendor for disclosure. After a patch was available, iDefense releases an advisory and pays you. Ignoring the fact that they would sit on the information for up to a year before disclosing it to the vendor, this program rewarded people for finding and disclosing vulnerabilities.

Months back, David Endler left iDefense to join Tipping Point, a division of 3Com. Shortly after, TP announced its “zero day initiative”. Like iDefense, the ZDI would pay for vulnerabilities, but also created a ‘loyalty’ program for continuing to disclose vulnerabilties through them (wonder if they give out keychain thingies like my grocery store does?).

Now, Digital Armaments is also offering a “pay for vuln” program. Instead of just offering cash for 0-day, they also offer trade-in credit so you can receive other 0-day in return for your own. This deviates off the path of “responsible disclosure” (questionable under the other two models) quite a bit.

Vendors Hate VDBs

[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.

Vendor Protection Rackets

[This was originally published on the OSVDB blog.]

I had planned on writing about this weeks ago but got swamped with that pesky day job along with the steady stream of new vulnerabilities released daily. That steady stream that absolutely will not get better with vendors taking a new approach to dealing with them. Fortunately for me, John Dvorak wrote an article and voiced some of my opinion as well. This comes some three years after Richard Forno wrote a related piece.

http://www.pcmag.com/print_article2/0,1217,a=162175,00.asp

The Microsoft Protection Racket
By John C. Dvorak

Does Microsoft think it is going to get away with charging real money for any sort of add-on, service, or new product that protects clients against flaws in its own operating system? Does the existence of this not constitute
an incredible conflict of interest? Why improve the base code when you can sell “protection”? Is Frank Nitti the new CEO?

So what is actually going on here? I think there were some bottom-line questions that must have been brought up internally. Obviously someone at Microsoft looked at the expense of “patch Tuesday” and asked, “Is there any way we can make some money with all these patches?” The answer was “Yeah, let’s stop doing them and sell ‘protection’ instead.” Bravo! And now the company has a new revenue stream.

What Dvorak doesn’t mention that is just as important, is that Microsoft is not the only one doing this. A colleague recently pointed out that Symantec is offering IDS/IPS solutions for their own software. So instead of truly patching a vulnerability, they can quickly write a rule/filter to stop attacks against a specific/known attack. While this is often effective, history shows us that such solutions often fall victim to being bypassed with crafted requests, altering exploit code or using various evasion techniques.

SYM05-011 – August 12, 2005
VERITAS Backup Exec for Windows Servers, VERITAS Backup Exec for NetWare Servers, and NetBackup for NetWare Media Server Option Remote Agent Authentication Vulnerability

Revision History
8/12/2005 – Revision One – updated details, affected products and response information.
8/12/2005 – Revision Two – Adding Tech Support links to currently available product updates as tested and posted for download by Symantec engineers. Link to IDS/IPS signatures for Symantec Security products.
8/13/2005 – Revision Three – Added Tech Support link to additional product updates. All supported affected products have updates available now.
8/14/2005 – Revision Four – Added links to IDS/IPS signatures for additional security products. All relevant Symantec Security products have signatures available now.

Again, what is the motivation/incentive for a vendor to patch a vulnerability, when they can just as easily ignore it, and spend time developing a profitable workaround or additional product?

Disclosure: Apache Tomcat 4.0.3 MS-DOS Device Request Handling Remote Path Disclosure

[This was originally sent to CVE and Nikto and then published on OSVDB, now gone. It was discovered in an old version of Apache Tomcat and the solution had existed for several years. VulnDB 20033]

From: security curmudgeon
To: Steven Christey , Sullo of Nikto
Date: Thu, 13 Oct 2005 14:21:33 -0400 (EDT)
Subject: Apache Tomcat 4.0.3 MS-DOS Device Request Path Disclosure

Didn’t see this in CVE or OSVDB. There is a known issue with several web servers including Resin, that when requesting a file that matches a MS-DOS file name, it will error out. Such errors will sometimes include installation path information.

While testing a few servers, the Nikto check for this triggered, but the server wasn’t Resin:

Nikto check that triggered:

  • OSVDB-0: GET /lpt9.xtp : Resin 2.1 reveals the server path when a DOS device is requested.

Actual server:

  • Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)

To verify:
http://%5Btarget%5D:5225/lpt9.xtp
Apache Tomcat/4.0.3 – HTTP Status 500 – Internal Server Error

type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request.

exception

java.io.FileNotFoundException: C:\Program
Files\Hewlett-Packard\Toolbox2.0\Apache Tomcat 4.0\webapps\ROOT\lpt9.xtp (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(Unknown Source)
at java.io.FileInputStream.(Unknown Source)
[..]

National Cyber Security Awareness Month

[This was originally published on the OSVDB blog.]

October has been named “National Cyber Security Awareness Month” by some. From a news article about this:

New York State, the University of North Carolina and the city of Charlotte, N.C., are joining the Department of Homeland Security, the National Cyber Security Alliance and numerous companies from the computer security industry to promote educational initiatives and free software giveaways to encourage the adoption of good cyber security practices in small businesses and citizens’ homes.

While security alliances, states and cities are grabbing their pom-poms, I’ll play the role of cynic. This awareness month means nothing to security companies and software developers that practice good security year round. As the article says, this awareness month is for businesses and end users which is good in theory. But will it help? You can answer this yourself actually. Find a friend or neighbor and ask them what other things we are supposed to be ‘aware’ of in the month of October. If your friend can’t remind you that it is National Breast Cancer Awareness Month, Domestic Violence Awareness Month, Down Syndrome Awareness Month, National Disability Employment Awareness Month, Energy Awareness Month, or Lupus Awareness Month, then this awareness month may fail too. Did you know there were more? Check out this great list of “Bizzare, Crazy, Silly, Unknown Holidays & Observances in October”.