Monthly Archives: July, 2005

OSVDB at Defcon

Several project leaders and OSVDB volunteers will be attending Defcon 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?!)!

XSS of the Third Kind

http://www.webappsec.org/projects/articles/071105.shtml

The Web Application Security Consortium is proud to present ‘DOM Based Cross Site Scripting or XSS of the Third Kind: A look at an overlooked flavor of XSS ‘ written by Amit Klein. In this article Amit focuses on a little known variant of Cross Site Scripting which attacks a user’s client without sending malicious content to the web server.

Zero Day Vulnerabilities – Sell Your Soul?

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

http://archives.neohapsis.com/archives/bugtraq/2005-07/0238.html

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.

[..]

http://archives.neohapsis.com/archives/bugtraq/2005-07/0239.html

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:
http://archives.neohapsis.com/archives/bugtraq/2005-07/thread.html#238

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?

ICAT -> NVD

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

http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0295.html

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:

[..]

HTTP Request Smuggling

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.

Follow

Get every new post delivered to your Inbox.

Join 5,408 other followers