Monthly Archives: March, 2006

Pink Hearts

Maybe I am immature but does anyone else find the Hitachi Incident Response Team logo a bit amusing?

Pink hearts, yellow XSS, orange SQL, blue DoS and green overflows!

CVE Commentary

CVE editor Steven Christey has begun to post commentary related to CVE and VDBs.

[20013-07-07 Update: This effort didn't last long. The last update was 2006-02-16, 4 days after this blog post. =(]

For Sale: VDB

Jason Bergen posted to Full-Disclosure trying to sell a “Security Vulnerability Database Company“. From that mail:

The company maintains a database of all security vulnerabilities, and the database is updated on a daily basis. The company maybe of interest to organisations who are currently licensing a vulnerability database. In addition the company has developed some software applications built upon the vulnerability database.

This is interesting on many levels, especially the approach in selling it. Why post to that mail list and not others? When asked for more details, Mr Bergen tells you “In order to provide further information a signed NDA would be required.” You must sign a non-disclosure agreement just to find out the name of the company being sold. He also makes the following claim:

The database contains all vulnerabilities since 1988. Each entry has Bugtraq, CVE, and Nessus ids. It has developed its own vulnerability alerting system, but recently changed focus to providing OEM database licensing.

Sadly, he is not the first to make this claim. Throughout the years, many people have referred to CVE as having “all vulnerabilities since 1988” which simply is not the case. If you ask Steve Christey or anyone involved with CVE, they will be the first to tell you that isn’t the case. So why do people think that? CERT started releasing advisories in 1988, but only released them for serious/critical vulnerabilities. Between 1988 and 1999 (CVE inception), many vulnerabilities were never added or given a formal advisory for. In short, claims that their database has “all vulnerabilities since 1988″ is extremely suspect. Had it been any year other than 1988, perhaps they took the time to go back and add them making the claim true. His wording also begs the question, what if a vulnerability doesn’t have a BID, CVE or Nessus ID to match? As much as databases try to maintain a perfect cross reference mapping, it just doesn’t happen all the time.

Depending on how you count flaws..[..]/0,10801,109278,00.html

After flap, Symantec adjusts browser bug count
Depending on how you count flaws, either IE or Firefox could be considered less secure
News Story by Robert McMillan

MARCH 07, 2006 (IDG NEWS SERVICE) – A report issued today by Symantec Corp. seeks to satisfy users of both Mozilla Corp.’s Firefox browser and Microsoft Corp.’s Internet Explorer.

In its latest Internet Security Threat Report, covering the last six months of 2005, the company now features two different ways of counting browser bugs: one that finds that Internet Explorer has the most vulnerabilities, and a second that reveals Firefox as the bug leader.

Thank you Symantec, for generating completely useless vulnerability statistics. When you can manipulate them to support either side of an argument (and do so intentionally), what’s the point? Just define your criteria for counting a vulnerability, define your time frame, and let the results speak for themselves.

Amusing Disclosure Timelines 101

We’ve all seen the standard disclosure timeline for a vulnerability. Date discovered, date reported to vendor, date patched, date disclosed. Once in a while, they are a bit more amusing.

McAfee notified 2006/02/17, denied responsability for the product and referred to Apple.
Apple notified 2006/02/17, denied responsability for the issue and referred to McAfee.
Published 2006/02/28 on Bugtraq.

Researcher Punished for Finding Bugs

Harvard University researcher punished for finding bugs

By Munir Kotadia, ZDNet Australia
28 February 2006 04:48 PM

French security expert Guillaume Tena has lost an appeal and been fined in a closely watched case which could have widespread ramifications for the way security researchers publish information about flaws in products.

The brouhaha kicked off in 2001 when Tena — who at the time was known by his pseudonym Guillermito — found a number of vulnerabilities in Tegam’s Viguard anti-virus software.


article: The value of vulnerabilities

The value of vulnerabilities
Jason Miller, 2006-03-07

There is value in finding vulnerabilities. Yet many people believe that a vulnerability doesn’t exist until it is disclosed to the public. We know that vulnerabilities need to be disclosed, but what role do vendors have to make these issues public?

Where do vulnerabilities come from? [..]
The value in vulnerabilities [..]
The ethics of vulnerabilities [..]
Why we need responsible, public disclosure [..]

What a Tangled Web of Code We Weave

While digging around the usual sources of vulnerability information tonight, I ran into this sequence of links trying to find where an underlying vulnerability really was:

1. sux0r 1.6 was released to fix a vuln
2. this was due to a vuln in MagpieRSS, which v 0.72 fixed
3. the MagpieRSS issue was due to a vuln in Snoopy

At this point, the sux0r release was linked two steps back to Snoopy, via MagpieRSS. This leads me to stress the value of vendors including such details in their release notes and changelogs. It can save people a lot of time when trying to figure this stuff out. Also attached to the same original vulnerability:

4. Ampache was also found to be using Snoopy
5. Jinzora was also found to be using Snoopy

Obviously, most people in the security industry who read Bugtraq or Full-Disclosure for their only source of vulnerability information didn’t see all of this. Unless they are as deranged an anal retentive as I am, or monitor several vulnerability databases, they may have missed the fact that several software packages had a fairly serious vulnerability. This is a good example of the value-add that some vulnerability databases offer due to their follow-up research and organization.

I also have to wonder if the authors of sux0r know that one of the packages they use, also uses other packages. This makes me wonder how many layers deep some of the software goes these days, and if the authors of these packages fully grasp the web of code and dependencies that are created. Imagine having a really accurate mapping of such relationships and integration, that would let us see just how far one vulnerability can spread into different codebases. A while back, I mentioned how this would be incredibly helpful to vulnerability databases in some cases. Imagine having this same type of system that linked software package integration and dependencies. When a given package is found to contain a vulnerability, you could instantly know that it likely affects seven other software distributions, all of which need to upgrade their dependencies or fix the issue themselves. I know, pipe dream but still a nice thought!

Vendor Confidence

Lance James of Secure Science Corporation posted an advisory detailing a serious flaw in the Fedex/Kinkos ExpressPay smart card payment system. A knowledgeable attacker with relatively minor resources can abuse the system to defraud the company. In response to the advisory, Fedex/Kinkos replied to them saying:

“Our analysis shows that the information in the article is inaccurate and not based on the way the actual technology and security function. Security is a priority to FedEx Kinko’s, and we are confident in the security of our network in preventing such illegal activity.”

Secure Science replied with an image of a receipt showing that it can be done. In case that wasn’t enough for some skeptics, they also released a video showing the abuse in action. Hopefully this will encourage Fedex/Kinkos to change their stance and take back the comment about their confidence in the security of their network/technology. This whole incident reminds me of the l0pht’s catchy slogan: “Making the theoretical practical since 1992

Mac vs Windows – More “Statistics”

Yet another article comparing Mac vs Windows, and using statistics to back it up. Since this is getting to be a common occurrence, I won’t go into the usual lecture about statistics, how they can easily be manipulated to back any argument (including how VAX/VMS is the most in/secure OS in the world!), how you must fully qualify the data you used to generate your statistics, and all the other tricks that make statistics the best tool to create a convincing argument (lie?). I’m not saying this because I think Mac or Windows is more or less secure. I’m saying this because I don’t feel the following article is accurate or well written. Even the readers who commented bring up some very valid points and questions for the author. Add to that it seems that the author (George Ou) is somewhat outspoken and a fan of Microsoft, his credibility and bias toward rivals comes into question. I’d love for Secunia to officially respond to this article, since he uses their database and rating system to generate his stats.

George Ou’s relevant conclusions: Between Feb 04 and Feb 06, Mac OS X had 5 “extremely critical” (1 unpatched) vulnerabilities and MS Windows had 2 “extremely critical” (0 unpatched) vulnerabilities. Mac OS X had 173 high and 59 moderate vulns, while MS Windows had 49 high and 41 moderate vulns. Ou goes to conclude “The data is clear, and Apple has a lot more vulnerabilities of every kind ranging from moderately critical to extremely critical.

Vulnerability statistics for Mac and Windows

One of many good comments challenging the piece:[..]messageID=356498&start=-1

Past criticism of Ou’s work, and signs he may be biased toward Microsoft:


Get every new post delivered to your Inbox.

Join 4,759 other followers