Monthly Archives: April, 2006

Microsoft Silently Patches…

Sure, the news that Microsoft silently patches vulnerabilities made the rounds. But honestly, who was surprised in the least? We’ve all known it is a common practice among many vendors, not just Microsoft. As you may have guessed, the reasoning behind this practice is a commonly heard justification:

“We want to make sure we don’t give attackers any [additional] information that could be used against our customers. There is a balance between providing information to assess risk and giving out information that aids attackers,” Mike Reavey said.

OK, we can buy that up to a certain point. So how about just saying “This patch also fixed X internally discovered vulnerabilities during internal audits.” At least give us an idea just how big the patch really is and help us figure out just how many vulnerabilities are being patched. That doesn’t give the bad guys enough information to act on.

OSVDB Selected for Google’s Summer of Code 2006

We are very pleased to report that OSVDB was selected for Google’s Summer of Code! This is great news as we hope to get some of the services and projects that have been on the back burner due to lack of development resources finally launched!

You can read about Google’s SoC here: http://code.google.com/soc/

With our Summer of Code project work, we hope to make several exciting enhancements to OSVDB’s public services. We have provided a list of important projects we are currently planning for–however we are open to proposals for other projects and ideas.

You can read about OSVDB’s Project Ideas here: http://www.osvdb.org/summerofcode.php

OSVDB has been working very hard to provide many additional types of a services to the community. Unfortunately, as mentioned due to lack of development resources we have been unable to make much of this happen. We now have an opportunity to possibly deliver on the OVSDB Portal and OSVDB Ethical Disclosure Framework commitments that we made when the project first opened.

You can read the public announcements with our intentions to provide OSVDB portal and disclosure services:

OSVDB Objectives: http://www.osvdb.org/OSVDB-Objectives.php

Vendor Dictionary Announcement: http://www.osvdb.org/news.php#vendorDictSiteUpgrade

Personally, I am absolutely thrilled that we may have the resources to develop the OSVDB Ethical Disclosure Framework. This has been one of the projects that I have been wanting for years and is validated as we see more and more issues with the disclosure process! I have believed all along that OSVDB can be the service that helps to improve, streamline and more importantly removes the mystery of the breakdowns in the process.

OSVDB has been handling one-off disclosures for researchers over the past 3-4 years and it is not an easy task. The amount of time it takes to handle a disclosure process is huge. We realized early on that a lot of the process needed to be automated in order to be successful and repeatable. Hopefully, there are some students out there that want to be apart of creating this service and we can get it launched by the end of the year!

We plan to post updates to the OSVDB blog as we get further in the process. If you have other ideas for projects that we should post please feel free to contact us at moderators@osvdb.org

Just Because It Is A Game..

Does the nature of a product determine vulnerability status? Without giving much thought, most people would classify a ‘game’ as nothing of concern. No way it could possibly pose a security threat to you.. besides, it’s fun! In reality though, games are just as likely to bite you in the ass as any other software including your web browser or blog software.

Luigi Auriemma is probably the most prevalent researcher for finding vulnerabilities in game software. For over a year now, he has found serious vulnerabilities in a wide range of games including Doomsday, X-Doom, Alien Arena, the Cube Engine, Monopd, Freeciv, FlatFrag, Glider, Scorched 3D, World Poker, Race Driver, Sacrifice, NetPanzer, Stronghold, Terminator, Warrior Kings, Halo, Yager, Star Wars Academy … oh, yah, I’ll stop now. And yes, the list goes on for many more pages. These vulnerabilities include trivial crashes, remote denial of service, remote overflows, format strings and more, including some fairly unique testing that many researchers tend to ignore. Running your favorite game one minute, getting owned by someone across the world the next. Laugh all you want, but they are just as important to be concerned about as any other vulnerability, if not more so.

This leads to a natural question for VDBs, what constitutes a vulnerability in a game? Obviously, remote exploitation that allows privileged access or trivial denial of service counts. But what about inside a game? As prompted by my recent digging into the Empire game, some of the changelog entries made me think of this. Consider the following:

  • Don’t reseed the PRNG in commands, it hurts randomness and could be abused by crafty players.
  • Fix major bug in transport that allowed two cooperating countries to duplicate items.
  • Close major loophole in drop that allowed players to determine whether an arbitrary sector is sea, allied land, or other land.
  • Close loophole in bomb that allowed players to find all sanctuaries.

So, do any of those qualify as vulnerabilities? It is easy to dismiss these as in game ‘cheats’ or giving one player an ‘advantage’ over another. In other systems, manipulating data or disclosing sensitive information is a serious risk, but is it the same for games? One may argue ‘no’, it’s just a game, so what if someone cheat a little bit. Other’s may argue ‘yes’, you are abusing the system and negatively impacting the gaming experience for others unfairly while increasing your own privileges without authorization. Finding a middle ground, what about games that are not so casual, and are methods for making money? How about games you pay to play? Is it an “advantage” or a “vulnerability” that someone can duplicate in-game currency at will before turning around and selling it online for real money?

Just Because It Is A Game..

Does the nature of a product determine vulnerability status? Without giving much thought, most people would classify a ‘game’ as nothing of concern. No way it could possibly pose a security threat to you.. besides, it’s fun! In reality though, games are just as likely to bite you in the ass as any other software including your web browser or blog software.

Luigi Auriemma is probably the most prevalent researcher for finding vulnerabilities in game software. For over a year now, he has found serious vulnerabilities in a wide range of games including Doomsday, X-Doom, Alien Arena, the Cube Engine, Monopd, Freeciv, FlatFrag, Glider, Scorched 3D, World Poker, Race Driver, Sacrifice, NetPanzer, Stronghold, Terminator, Warrior Kings, Halo, Yager, Star Wars Academy … oh, yeah, I’ll stop now. And yes, the list goes on for many more pages. These vulnerabilities include trivial crashes, remote denial of service, remote overflows, format strings and more, including some fairly unique testing that many researchers tend to ignore. Running your favorite game one minute, getting owned by someone across the world the next. Laugh all you want, but they are just as important to be concerned about as any other vulnerability, if not more so.

This leads to a natural question for VDBs, what constitutes a vulnerability in a game? Obviously, remote exploitation that allows privileged access or trivial denial of service counts. But what about inside a game? As prompted by my recent digging into the Empire game, some of the changelog entries made me think of this. Consider the following:

  • Don’t reseed the PRNG in commands, it hurts randomness and could be abused by crafty players.
  • Fix major bug in transport that allowed two cooperating countries to duplicate items.
  • Close major loophole in drop that allowed players to determine whether an arbitrary sector is sea, allied land, or other land.
  • Close loophole in bomb that allowed players to find all sanctuaries.

So, do any of those qualify as vulnerabilities? It is easy to dismiss these as in game ‘cheats’ or giving one player an ‘advantage’ over another. In other systems, manipulating data or disclosing sensitive information is a serious risk, but is it the same for games? One may argue ‘no’, it’s just a game, so what if someone cheat a little bit. Other’s may argue ‘yes’, you are abusing the system and negatively impacting the gaming experience for others unfairly while increasing your own privileges without authorization. Finding a middle ground, what about games that are not so casual, and are methods for making money? How about games you pay to play? Is it an “advantage” or a “vulnerability” that someone can duplicate in-game currency at will before turning around and selling it online for real money?

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.

The Price of Restricting Vulnerability Publications

The Price of Restricting Vulnerability Publications
by d2d

http://www.ijclp.org/Cy2004/ijclpwebdoc10_Cy2004.htm
The Price of Restricting Vulnerability Publications by Jennifer Stisa Granick

Abstract

There are calls from some quarters to restrict the publication of information about security vulnerabilities in an effort to limit the number of people with the knowledge and ability to attack computer systems. Scientists in other fields have considered similar proposals and rejected them, or adopted only narrow, voluntary restrictions. As in other fields of science, there is a real danger that publication restrictions will inhibit the advancement of the state of the art in computer security. Proponents of disclosure restrictions argue that computer security information is different from other scientific research because it is often expressed in the form of functioning software code. Code has a dual nature, as both speech and tool. While researchers readily understand the information expressed in code, code enables many more people to do harm more readily than with the non-functional information typical of most research publications. Yet, there are strong reasons to reject the argument that code is different, and that restrictions are therefore good policy. Code¹s functionality may help security as much as it hurts it and the open distribution of functional code has valuable effects for consumers, including the ability to pressure vendors for more secure products and to counteract monopolistic practices.

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?

Bugs and Money

Bugs and Money
by d2d

Jennifer Granick has a good article up on Wired titled “Bug Bounties Exterminate Holes,” which talks about some of the issues raised in a panel discussion at CanSec last week. She makes some good points about commercialization of vulnerability research–pros and cons, risks and rewards, etc.

It’s well worth reading the whole article, but one small bit caught my eye…

I have advised two businesses that had plans to auction vulnerabilities to the highest bidder on eBay. (After talking with me, each decided not to take the risk.)

This is pretty disappointing. I would love an environment where software vendors are forced to pony-up cash to researchers if they want bug details, and are forced into a competitive market against “value-add” services (iDefense, ZDI, etc.), and even criminals. Some may see this as a form of blackmail, but I think it will shed some much-needed light on how vendors feel about security, and how much money they are really willing to spend to keep their customers safe. Already we see a non-profit organization (Mozilla) willing to pay $500 for the information, and multi-billion dollar companies unwilling to pay anything.

I realize there are many legal and ethical problems with auctioning vulnerabilities that need to be wrestled with (including problems with eBay), but would it really be worse than it is right now?

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

The Open Source Vulnerability Database (OSVDB) has, from the beginning, been a database built and maintained for the community, by the community. In an effort to further that mission, the project has recently added the ability for security practitioners to comment on vulnerabilities in OSVDB.

There are mail list discussions, blogs, bug tracking systems, and many other forums for clarifying vulnerability information. Such follow-up often adds information like affected versions, exploitation caveats and additional attack vectors. Unfortunately, this information is often spread out among many sources and remains mostly unknown to a large portion of the community that uses and relies on such details.

While OSVDB has made every effort to include such references in some fashion, we have always desired a better and more concise method for the community to add information about a vulnerability. To help facilitate this, OSVDB will now allow users to comment on specific vulnerabilities. The project hopes this will provide a place for additional information to be maintained in a consolidated location. All user submissions will be moderated to ensure the information is clear, concise and helpful to others.

As always, the OSVDB project thanks you for your support, and continues to look for additional volunteers to help update the content and develop new services. For more information on supporting OSVDB through volunteering or sponsorship, please contact moderators@osvdb.org.

Follow

Get every new post delivered to your Inbox.

Join 5,026 other followers