Monthly Archives: March, 2006

Vulnerability History

Steven Christey (CVE) recently posted about vulnerability history and complexity. The recent sendmail vulnerability has brought up discussion about both topics and adds another interesting piece of history to the venerable sendmail package. One point to walk away with is that while sendmail has a long history of vulnerabilities, the last five years have shown the product to be considerably more secure. While overflows still haunt the ~ 25 year old software package, they are growing fewer and requiring considerably more complex methods to exploit them. The latest discovery is by no means a run-of-the-mill remote overflow, rather it takes considerable skill to find and exploit the flaw.

Using vulnerability history to help evaluate the current security posture of software is a bit sketchy, but certainly helps. If a program starts out with standard overflows, race conditions, symlink issues, XSS or SQL injections, it’s basically expected. If years pass and new versions of the same package continue to exhibit the same coding practices that lead to these vulnerabilities, you begin to get an idea of the quality of code as it relates to security. On the other hand, if years pass and the vulnerabilities are published with more time between each, and the difficulty exploiting them increases, it shows the developers are security conscious and producing more secure code. As always, the lack of published vulnerabilities in a product doesn’t mean it is free from defect, just that they possibly have not been found or published.

Fun fact: The first documented Sendmail vulnerability was on Aug 23, 1981.

The Web Hacking Incidents Database

The Web Hacking Incidents Database

The web hacking incident database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. WHID goal is to serve as a tool for raising awareness of the web application security problem and provide the information for statistical analysis of web applications security incidents.

The WHID is an interesting new database that seems to be a cross between a database of site specific vulnerabilities (something OSVDB has considered maintaining) and the Attrition Dataloss page.

Vulnerability History

Steven Christey (CVE) recently posted about vulnerability history and complexity. The recent sendmail vulnerability has brought up discussion about both topics and adds another interesting piece of history to the venerable sendmail package. One point to walk away with is that while sendmail has a long history of vulnerabilities, the last five years have shown the product to be considerably more secure. While overflows still haunt the ~ 25 year old software package, they are growing fewer and requiring considerably more complex methods to exploit them. The latest discovery is by no means a run-of-the-mill remote overflow, rather it takes considerable skill to find and exploit the flaw.

Using vulnerability history to help evaluate the current security posture of software is a bit sketchy, but certainly helps. If a program starts out with standard overflows, race conditions, symlink issues, XSS or SQL injections, it’s basically expected. If years pass and new versions of the same package continue to exhibit the same coding practices that lead to these vulnerabilities, you begin to get an idea of the quality of code as it relates to security. On the other hand, if years pass and the vulnerabilities are published with more time between each, and the difficulty exploiting them increases, it shows the developers are security conscious and producing more secure code. As always, the lack of published vulnerabilities in a product doesn’t mean it is free from defect, just that they possibly have not been found or published.

Fun fact: The first documented Sendmail vulnerability was on Aug 23, 1981.

Microsoft Opens IE Bug Database

Microsoft Opens IE Bug Database

Microsoft has established a public database to allow Internet Explorer users to report bugs in the Web browser.

To post or view bugs, users must sign up for a Passport account on the Microsoft Connect Web site.

Microsoft plans to allow non-registered users to view reported bugs in a couple of months, according to a post on the Internet Explorer Weblog.

[..]

Microsoft is only accepting bug posts for Internet Explorer 7 and future versions.

The last line is curious. I understand a vendor’s motive for not supporting a product it considers old, and not updating it. I even understand a vendor saying “from here on out, no updates, including security updates”. However, MSIE6 will be heavily used for years to come, and will remain a large part of personal and corporate user installations. MSIE6 consists of a lot of code and represents a decade of work from Microsoft. Pointing out bugs in security or functionality should be of interest to them, even if they plan to completely ditch version 6. Such bugs would help them learn more about how the code is used and abused, and help them from making the same mistakes in future releases.

On the Value of Automated Code Scanners

CodeScan Labs recently disclosed that their new product was used on ASP Portal to look for vulnerabilities. These types of scanners are automated and check for common programming errors that lead to vulnerabilities. These types of tools have been around for many years, but are starting to mature quickly. However, one has to wonder just how effective they can be:

2006-03-02 – ASP Portal announces version 3.1.0 which contains “CodeScan security fixes”
2006-03-03 – ASP Portal announces version 3.1.1 which contains “a critical security Fix” (in news_item.asp)
2006-03-14 – CodeScan discloses their tool found 10 SQL injections and over 50 cross-site scripting vulns
2006-03-20 – nukedx releases a working exploit for an SQL injection (in download_click.asp)
2006-03-21 – nukedx releases details for 10 SQL injections in 3.1.1 including one in news_item.asp

So CodeScan finds 10 SQL injections, but doesn’t find the 11 others that nukedx finds a week later, and doesn’t find the “critical” issue in news_item.asp either. Hopefully these tools continue to mature very quickly. Maybe some day, cross-site scripting vulnerabilities will be a thing of the past! Hah yeah right, if that were true, overflows and race conditions wouldn’t pop up every few days either.

FrSIRT Puts Exploits up for Sale

FrSIRT Puts Exploits up for Sale
By Ryan Naraine
March 15, 2006

Independent security research outfit FrSIRT.com is putting its database of security exploits behind the paid curtain.

FrSIRT, previously known as K-Otik, has shut down the public exploits section of its Web site and announced that all exploits and
proof-of-concept code will be sold through its subscription-based VNS (Vulnerability Notification Service).

Since they presumably didn’t write a majority of their exploits, what is the motivation for people to keep sending in such code if it will be used for profit? Wouldn’t exploit writers send it to Securiteam or another site that focuses on the code more than vuln tracking?

US Government Studies Open Source Quality

US Government Studies Open Source Quality reads the SlashDot thread, and it certainly sounds interesting. Reading deeper, it links to an article by the Reg titled Homeland Security report tracks down rogue open source code. The author of the article, Gavin Clarke, doesn’t link to the company who performed the study (Coverity) or the report itself. A quick Google search finds the Coverity home page. On the right hand side, under ‘Library’, there is a link titled NEW >> Open Source Quality Report. Clicking that, you are faced with “request information”, checking the “Open Source Quality Report” box (one of seven boxes including “Request Sales Call” as the first option, and “Linux Security Report” is the default checked box), and then filling out 14 fields of personal information, 10 of which are required.

So, let me get this straight. My tax dollars fund the Department of Homeland Security. The DHS opts to spend $1.24 million dollars on security research, by funding a university and two commercial companies. One of the commercial companies does research into open source software, and creates a report detailing their findings. To get a copy of this report, you must give the private/commercial company your first name, last name, company name, city, state, telephone, how you heard about them, email address, and a password for their site (you can optionally give them your title, and “describe your project”).

Excuse me, but it should be a CRIME for them to require that kind of personal information for a study that I helped fund via my tax dollars. Given this is a study of open source software, requiring registration and giving up that kind of personal information is doubly insulting. Coverity, you should be ashamed at using extortion to share information/research that should be free.

Even worse, your form does not accept RFC compliant e-mail addresses (RFC 822, RFC 2142 (section 4) and RFC 2821). Now I have to add your company to my “no plus” web page for not even understanding and following 24 year old RFC standards. HOW CAN WE TRUST ANYTHING YOU PUBLISH?!

Oh, if you don’t want to go through all of that hassle, you can grab a copy of the PDF report anyway.

The Excel Pebble

Back on December 8th, 2005, I posted a comment about someone who created an eBay entry for a “Brand new Microsoft Excel Vulnerability”. The vulnerability was never sold via eBay, but may have traded hands through other means. For the most part, this incident faded into the background but I think this was the proverbial pebble thrown into the pond. Jump forward to yesterday, and Microsoft released an advisory covering multiple vulnerabilities in Excel. While chatting with one of the OSVDB manglers, I began to think out loud about why we would see so many Excel vulnerabilities released at once, and I think it became clear.

Remote Code Execution Using a Malformed Range – CVE-2005-4131
Remote Code Execution Using a Malformed File Format – CVE-2006-0028
Remote Code Execution Using a Malformed Description – CVE-2006-0029
Remote Code Execution Using a Malformed Graphic – CVE-2006-0030
Remote Code Execution Using a Malformed Record – CVE-2006-0031
Remote Code Execution Using a Malformed Routing Slip – CVE-2006-0009

Looking back at the original eBay entry, the poster said “all the details were submitted to Microsoft, and the reply was received indicating that they may start working on it. It can be assumed that no patch addressing this vulnerability will be available within the next few months.” The technical details released at the time stated “Microsoft Excel does not perform sufficient data validation when parsing document files. As a result, it is possible to pass a large counter value to msvcrt.memmove() function which causes critical memory regions to be overwritten, including the stack space.”

Note the CVE assignments for each of the vulnerabilities listed above. CVE-2005-4131 covers the eBay Excel 0-day. Shortly after that, we see CVE-2006-00xx assigned for five more Excel vulnerabilities and it is pretty clear what happened. Ollie Whitehouse, Peter Winter-Smith, Dejun, Eyas and Arnaud Dovi (via TP) all probably tried to find more details on the posted 0-day. In doing so, they discovered additional vulnerabilities in Excel and thankfully (for Microsoft) followed a responsible disclosure policy. This turned out to be an interesting byproduct of an amusing eBay listing.

Where’s my 0day, please?

Where’s my 0day, please?
Tuesday, March 07, 2006
Dancho Danchev

A site I was recently monitoring disappeared these days, so I feel it’s about time I blog on this case. I have been talking about the emerging market for software vulnerabilities for quite some time, and it’s quite a success to come across that the concept has been happening right there in front of us.

[..]

As there’s been already emerging competition between different infomediaries that purchase vulnerabilities information and pay the researchers, researchers themselves are getting more and more interested in hearing from “multiple parties”. Turning vulnerability research, and its actual findings into an IP, and offering financial incentives is tricky, and no pioneers are needed in here!

Vulnerability Markets

There has been a steady stream of papers and research examining the market for vulnerabilities. Countless people have blogged on it in passing and more people are starting to take interest in it for many reasons. Here are a couple papers (courtesy of Danchev’s blog) that cover the issue. When I find time, I hope to dig up links to others I have seen mentioned, as well as dig into the footnotes of these.

Vulnerability Markets: What is the economic value of a zero-day exploit?
Rainer Bohme – Dec 27, 2005

Market for Software Vulnerabilities? Think Again
Karthik Kanna, Rahul Telang – Dec 12, 2004

An Economic Analysis of Market for Software Vulnerabilities
Karthik Kanna, Rahul Telang – May 3, 2004

Follow

Get every new post delivered to your Inbox.

Join 4,759 other followers