[This was originally published on the OSVDB blog.]

Several project leaders and OSVDB volunteers will be attending DEF CON 13 later this week. If you would like to meet up, hang out, ask questions or pledge time (booze?!), feel free to track us down. Odds are we will be around the Alexis Park pool during the evening hours. We might even have some stickers to hand out (trade for booze?!)!

Zero Day Vulnerabilities – Sell Your Soul?

[This was originally published on the OSVDB blog.]

There have been several Vulnerability Sharing Clubs (VSC) in the past including iDefense, Immunity and others. For those who question this business model, consider Verisign just purchased iDefense for US $40 million. Still not a believer? Consider 3Com/TippingPoint is now offering a new VSC called the Zero Day Initiative. Now instead of just selling an exploit for cash, you can earn points and trade them in for cash and prizes! Since this new program is being lead by David Endler, who was an early participant in the creation of the iDefense VSC, this business model appears to be very sound (for the time being). In response, iDefense/Verisign has announce that not only is it continuing their program, it is beefing it up and offering more money for the 0-day. For the skeptics out there, you are not alone. Frank Knobbe wrote a really good response to the 3Com/TP announcement, questioning the nature of the vulnerabilities that would be shared. I tend to agree with many points of this.

Other random thoughts:

  • VSCs typically receive a 0-day vulnerability, share the info with their clients, then disclose the vuln to the vendor, give them all the time they want for a patch and eventually publish the information (presumably when it has little/no value). Verisign may now give iDefense a better opportunity to know when the 0-day is worthless via its customer networks they monitor. Once they see the vulnerability in the wild, they know it isn’t 0-day and the value drops.
  • With the above model in mind, we now know the Verisign doesn’t care about the ethical dilemma of having 0-day vulnerability information, and not immediately disclosing it to the vendor. Even if they do share with the vendor immediately, they also share this information with clients who can leak the information out to other people.
  • With the above model in mind, we know that 3com/TippingPoint also doesn’t care about the ethical dilemma.
  • Is this the start of a trend regarding vulnerabilities, disclosure and the bottom line?
  • Will this be the precursor to half a dozen other companies offering similar programs?
  • If there are a dozen VSCs like this, are the vendors expected to pay for the information to receive it before the VSC decides to “responsibly disclose” said information to the vendor? (Remember, the vuln info usually stays in the hands of the VSC and it’s clients for months before vendor notification)

Vuln info from public sources and VDB ‘rules’?

[This was originally published on the OSVDB blog.]

This has come up in the past, and again more recently. Is information found on a vendor website, such as a changelog or bugzilla entry, fair game for inclusion in a vulnerability database? Some vendors seem to think this material is off limits. If a person keeps a directory of material regarding vulnerabilities, and it is not password protected or restricted in any way, are we to assume it may be private in some fashion?

The recent complaint does bring up another issue though; assigning vulnerable versions to the database entry. In this case, Secunia apparently listed 1.x when it was a specific release. SecurityFocus’ BID database tends to do this on many entries, listing all prior releases of a product as vulnerable when it hasn’t necessarily been tested. That may be a safe assumption with some software, but not always. As new features are added to a software package, so are new bugs and vulnerabilities.

VDBs using public information such as bug trackers and changelogs may have a long term negative impact though. The Caudium Group has closed its bug tracker to the public in response to Secunia’s vulnerability listing. If more vendors follow suit, this will make more detailed information unavailable to VDBs and impact the quality of the information we can provide.

Classification Headache: Remote vs Local

[This was originally published on the OSVDB blog.]


From: Derek Martin (code[at]pizzashack.org)
Date: Thu Jul 14 2005 – 21:39:30 CDT

The issue has come up on bugtraq before, but I think it is worth raising it again. The question is how to classify attacks against users’ client programs which come from the Internet, e.g. an e-mail carrying a malicious trojan horse payload. The reason this is important is because we judge how serious a particular vulnerability is based on how it is classified.



From: Bryan McAninch (bryan[at]mcaninch.org)
Date: Fri Jul 15 2005 – 10:58:47 CDT

I merely skimmed your post, so I apologize if the link I’m providing is not what you’re looking for. From what I read, it soundsas if you might be looking for an attack taxonomy, or something of that nature. An entire chapter of the Computer Security Handbook is devoted to this topic, written by John D. Howard and Thomas A. Longstaff. This document can also be found at CERT’s website – http://www.cert.org/research/taxonomy_988667.pdf

Full thread:

While this debate is very important to VDBs, the person who started the thread chose an extremely bad example. The real debate comes in for vulnerabilities that don’t require user interaction (ie: not having to click an attachment) such as image processing overflows. It is easy to argue this either way; the overflow exists in the local application, the content comes from a network resource.

Either way, every existing classification system (including OSVDB’d) fall back onto remote vs local, when it is becoming painfully obvious that it needs to evolve. Steven Christey (CVE) has made comments regarding this (before and during this thread), suggesting that we take note of attacks that are “user-complicit” vs “automatic”. This is certainly a large step in the right direction, but is it enough? Will this classification scheme last us a few more years?


[This was originally published on the OSVDB blog.]

Someone brought this to my attention: http://nvd.nist.gov/
National Vulnerability Database

Welcome to NVD!!
NVD is a comprehensive cyber security vulnerability database that integrates all publicly available U.S. Government vulnerability resources and provides references to industry resources. It is based on the CVE vulnerability naming standard.

NVD contains:
11708 Vulnerabilities
482 US-CERT Alerts
1085 US-CERT Vuln Notes
776 Oval Queries

Publication rate: 9 vulnerabilities / day

NVD is a product of the NIST Computer Security Division and is sponsored by the Department of Homeland Security’s National Cyber Security Division.

Check http://icat.nist.gov for details.

Why Vulnerability Databases Can’t Do Everything

[This was originally published on the OSVDB blog.]


From: Steven M. Christey (coley[at]mitre.org)
Date: Fri Jul 15 2005 – 13:35:52 CDT

Vulnerability databases and notification services have to pore through approximately 100 new public vulnerability reports a week. Correction: that’s HUNDREDS of reports, from diverse and often unproven sources, for about 100 unique vulnerabilities per week.

A LARGE number of vendors and maintainers either:


Disclosure: Whois.Cart Multiple Vulnerabilities

[This was originally published on OSVDB, now gone, and touched up for style. VulnDB 18533, 18534, 18535, 18536]

During communication with the vendor of Whois.Cart regarding previous entries, Alexandre Lemaire was very helpful and prompt in providing information for the OSVDB team to resolve outstanding questions. During the communication, a few low concern issues were found. Mr. Lemaire and his team fixed the issues within one hour of my mail.

Brian Martin

From: security curmudgeon jericho[at]attrition.org
To: S. Alexandre M. Lemaire saeven[at]saeven.net
Cc: Mods moderators[at]osvdb.org
Date: Fri, 8 Jul 2005 02:01:03 -0400 (EDT)
Subject: [OSVDB Mods] Re: [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access

Hi Alexandre,


In the mean time, while poking around http://whoiscart.net/demo/ I did
find some other valid XSS vulnerabilities.

/demo/admin/index.php “domains” option, clicking the + on the left then putting in as the domain name will create a persistent XSS. Clicking ‘save’ returns me to the demo main page and pops up my vulnerable warning. Each time that page loads, the script pops up again until I delete the domain.

Clicking the “hosts” option, create a new plan (or cyclic fee, or target) with the same script code, and it will render the script twice.

Clicking the “hosting” option, “Add Line to Hosting Plans”, the same script in the ‘Package’ field will render. THe “HKey” variable and others may be as well (difficult to tell if it’s the previous script rendering or new input).

The info.php page also provides a lot of information routinely considered sensitive (to the security community) including the installation path, configuration options, versions and more.

During one of these XSS attempts, a portion of SQL syntax appeared at the top of the page as well which hints at a possible SQL injection scenario.


From: S. Alexandre M. Lemaire saeven[at]saeven.net
To: security curmudgeon jericho[at]attrition.org
Date: Fri, 8 Jul 2005 02:42:47 -0400
Subject: Re: [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access


I'll have the most recent CVS snap uploaded to the server, and thank you

for your time with this. I’ve just released a patch version with respects
to your findings, thank you for having kindly conveyed them – just my luck
that you’d find something else whilst I’m trying to convince you that
something unrelated is otherwise ‘ok’.


HTTP Request Smuggling

[This was originally published on the OSVDB blog.]

Last month, Watchfire released a new paper describing “HTTP Request Smuggling” attacks. Since the release of this paper, many products have been found prone to such attacks. Some of these include SunONE Web Server, Oracle Application Server Web Server, IBM WebSphere, BEA WebLogic, Tomcat, Microsoft Internet Information Server, DeleGate Proxy, Sun Java System Web Proxy Server, Squid and Apache. This may qualify as the most recent class of vulnerability discovered and could prove interesting over the next few months as vendors scramble to diagnose their products.