Microsoft Silently Patches…

[This was originally published on the OSVDB blog.]

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.

Just Because It Is A Game..

[This was originally published on the OSVDB blog.]

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

[This was originally published on the OSVDB blog.]

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

[This was originally published on the OSVDB blog.]

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?