Category Archives: General Vulnerability Info

The Upside to the Provenance Problem

As mentioned before, Christey of CVE mentions an ongoing problem in the vulnerability world is that of “provenance”, meaning “where the hell did that come from?!” Vulnerability Databases (VDB’s) like CVE and OSVDB are big on provenance. We want to know exactly where the information came from and include it in our entry. Other VDBs like Secunia or SecurityFocus’ BID are bad about it. That is to be expected though, we’re talking free/open vs commercial/closed. BID/Secunia gain some value by appearing to be magical when it comes to finding vulnerability information.

For anal retentive freaks, the provenance problem does have one upside. For years now, OSVDB has been aggressive in digging up vulnerability information, regardless of age or severity. This typically means spending hours upon hours of reading changelogs, which usually are not the most stimulating reading one can find, and more often than not lack any form of clarity or simplicity. This also means relying on a bit of guesswork at times, as changelog entries tend to be short and sweet, leaving a lot to the imagination. One such example is the recently published Empire Server Unspecified Vulnerabilities from Secunia. As always, unspecified and no reference as to where the vulnerability information came from means looking at the vendor site, bug tracking systems, news archives, changelogs and more. An hour after digging, I still can’t find where exactly Secunia got “Some vulnerabilities with unknown impacts have been reported in Empire Server. The vulnerabilities are caused due to unspecified errors in the game server.” One of the OSVDB manglers (mdodge) was able to track down where this information came from while I was knee deep in changelog.

Despite that, OSVDB will soon have as many as 12 more entries for the Empire server from other Changelog entries, and I’m not even 10% done reading. I’m conflicted here.. part of me is sad, because the only other previous entry OSVDB has for this is an old entry dating back to 1981 and nothing since. That is depressing in the world of VDBs, and a discredit to what we do. Consider the entries in various VDBs: CVE 0, ISS 0, ST 0, BID 0, Secunia 1, OSVDB 2. Yet the changelog for the 4.x branch suggests over a dozen vulnerabilities?

The other part of me is happy as this is one more product that will be better represented in a VDB as far as security goes. People want better vulnerability trending, a more accurate vulnerability history and a better idea of a product’s security. That won’t happen without a more complete picture of the vulnerabilities in a given product.

10 Infamous Moments In Security Research

10 Infamous Moments In Security Research
InformationWeek – Apr 17, 2006

1. SQL Slammer
2. Windows Plug and Play
3. Cisco IOS heap overflow
4. Windows Metafile
5. Oracle transparent data encryption
6. Oracle PLSQL gateway
7. Apple Mac iChat
8. Internet Explorer createTextRange()
9. Internet Explorer HTA files
10. Sendmail SMTP server software

While many of these are notable events, this list seems very centered around the last couple of years and doesn’t consider the bigger picture. The initial discovery/disclosure of certain vulnerability classes (Overflow, XSS, SQL Injection) seem like they would be big moments. What else should have been on the list?

Beware of MS06-013, not just a security fix…

About a week ago I started receiving emails from vendors warning that if the upcoming Internet Explorer patch was installed it would break all of their applications. Some of the emails were fairly detailed and even explained that once the patch was installed there was no going back since it could not be uninstalled. I had not heard of anything prior to the emails but figured this month was going to be extra painful.

When reading the details for MS06-013 it becomes clear real quick that something is a bit off on this one when you get to the Caveats section.

From Microsoft’s website:

Caveats: Microsoft Knowledge Base Article 912812 documents the currently known issues that customers may experience when they install this security update. The article also documents recommended solutions for these issues. For more information, see Microsoft Knowledge Base Article 912812. […] Compatibility Patch – To help enterprise customers who need more time to prepare for the ActiveX update changes discussed in Microsoft Knowledge Base Article 912945 and included in Microsoft Security Bulletin MS06-013, Microsoft is releasing a Compatibility Patch on April 11, 2006. As soon as it is deployed, the Compatibility Patch will temporarily return Internet Explorer to the previous functionality for handling ActiveX controls. This Compatibility Patch will function until an Internet Explorer update is released as part of the June update cycle, at which time the changes to the way Internet Explorer handles ActiveX controls will be permanent. This compatibility patch may require an additional restart for systems it is deployed on. For more information, see Microsoft Knowledge Base Article 917425.

It appears that Microsoft has packaged a non-security update with the “Cumulative Security Update” that is going to change the way ActiveX controls work in order to circumvent a recent patent lawsuit. The spin on this being included in the patch appears to be increased ActiveX security.

The bottom line is that if you want to patch Internet Explorer this month you also are going to have a good chance of breaking quite a few applications as these other change has been packaged with the update. It appears to be impossible to get a patch that just corrects the vulnerabilities. Ah, but there is some hope as Microsoft did release that “Compatibility Patch” that will give you until June to fix everything!

What am I missing here?

Here is a good article that explains the issues.

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.

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.

CVE Commentary

http://cve.mitre.org/cve/edcommentary.html#community_issues

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. =(]

Follow

Get every new post delivered to your Inbox.

Join 5,028 other followers