Recently an executive at HP claimed that his company now employs 9 out of the top 11 security people due to HP’s acquisition of SPI Dynamics:

“Nine out of the world’s top 11 security hackers came to HP through the SPI Dynamics acquisition, he boasts, although it’s not immediately clear who ranked those top 11.”
- Mark Potts, CTO of Software, Hewlett-Packard

Now eWeek has produced a list of the 15 most influential people in security today. Here is the quick non-multimedia version:

1. Tavis Ormandy, Google Security Team
2. Ivan Krstic, One Laptop Per Child
3. Chris Paget, IOActive
4. Bunnie Huang, Bunnie Studios
5. Michal Zalewski, Google
6. Window Snyder
7. The MOAB Hackers
8. Dino Dai Zovi
9. Michael Howard, Microsoft
10. HD Moore, Metasploit
11. Dave Aitel, Immunity
12. Bronwen Matthews, Microsoft
13. John Pescatore, Gartner
14. Rob Thomas and Team Cymru
15. Stefan Esser, Hardened PHP Project

I don’t see any SPI Dynamics or HP people on this arguably less biased list. I do see 3 of my former collegues from @stake: Dave Aitel, Dino Dai Zovi, and Window Snyder. Seeing that giants Microsoft and Google only got 2 each on the list and @stake has 3 it lends credence that @stake was the place to be for hard core security people.

Wikipedia has a nice large list of computer security specialists.

There is an heap overflow vulnerability in RealPlayer 11 build 6.0.14.74. It allows for code execution when RealPlayer opens a malicious song file.

Timeline

Dec 16, 2007: Gleg customers notified of vulnerability and given exploit code

Jan 1, 2008: Public disclosure (no details) with online demonstration

Feb 6, 2008: Vulnerability still not patched

It’s not your typical disclosure time line. In recent years we have become accustomed to a disclosure time line that goes something like this:

Typical Timeline

Dec 16, 2007: Vendor notified of vulnerability and given exploit code

Feb 6, 2008: Public disclosure with details and vendor patch available

Feb 7, 2008: Some customers patched

We don’t know when this unpatched RealPlayer vulnerability was introduced into the code. It has probably been latent for many months. Real’s customers were vulnerable as soon as they downloaded this version of RealPlayer. Certainly, Real needs to increase its efforts to reduce security vulnerabilities in its shipping products. Still, the first disclosure time line is troubling.

Gleg knew how to reproduce this problem at least a month before yet they didn’t tell the vendor, just their customers. It’s unclear what benefit Gleg’s customers get from the vendor not knowing this information unless they use this information to compromise other systems, especially with this being a client side vulnerability.

In an eWeek article Gleg founder explains:

Gleg founder Evgeny Legerov confirmed his company’s refusal to share the RealPlayer exploit details, arguing that he needs “exclusivity” for a few months to help his customers understand the level of risk they face.

I guess I don’t quite get it. Without being a Gleg customer, even from the minimum information available, I already know I need a fixed RealPlayer and until then I need to block these files at my perimeter and disable RealPlayer. I know that users with RealPlayer 11 installed will undoubtedly stumble across a malicious music file and their system will have a bot installed running with their logged in privilege level. I’m not sure what additional value I would get as a Gleg customer.

Now on the other hand Real could simply become a Gleg customer, pay for the exploit, run it in their lab and diagnose the vulnerability. Then they could fix the vulnerability and we would have a time line closer to the second one. Still I don’t see the value, even in this scenario, of more organizations than the vendor knowing about the vulnerability details and getting the exploit.

A protocol that better protects the security of our software ecosystem would be for vulnerability finders to contract directly with the vendor to find vulnerabilities. Customers of the vendor could get high level summary information that the vulnerability exists and its type so they could weigh the risks of using the product and the vendor would get the details they need to remediate the vulnerability.

The above is how Veracode’s Vendor SecurityReview service works. Customers that are concerned about the security of software they are purchasing use Veracode as a 3rd party assessment service. We will contact the vendor and have them upload their software binary executable to our portal. We analyze the software and deliver a detailed report of the security issues we find in the code. We also generate a summary report for the customer to understand the security risks of the software.

A cooperative solution is a much safer way for customers to understand the risks of the code they run. After all do you want to know about just one vulnerability or see the summary of a comprehensive assessment. A cooperative solution also promotes good security hygiene on the vendor side. We have found that once vendors know that their big customers are using Veracode’s Vendor SecurityReview service they are more likely to proactively start doing security testing within their SDLC. A vendor can’t bluff their way out of a comprehensive code assessment like they can from just a single (or a few) vulnerabilities publicly reported. If their code is full of vulnerabilities their customers will know.

UPDATE 2/09/08: It seems the RealPlayer vulnerability being used in mass website attacks as reported by SANS ISC is not the same vulnerability at the unpatched Gleg RealPlayer vulnerability. As far as we know knowledge of this vulnerability is not being used in current attacks.

Now I can finally tell my non-technical friends and family what Veracode does. We offer a globally accessible, on-demand automated version of WTF reporting. However since our technology is automated we report quality in kiloWTF/sec.

On February 14th, Dawn Song of UC Berkeley is holding a seminar on binary analysis: TRUST Seminar: BitBlaze: a Binary-centric Approach to Computer Security. This seminar is open to the public.

Binary analysis is imperative for protecting COTS (common off-the-shelf) programs and analyzing and defending against the myriad of malicious code, where source code is unavailable, and the binary may even be obfuscated. Also, binary analysis provides the ground truth about program behavior since computers execute binaries (executables), not source code. In this talk, I will present the BitBlaze project, a binary-centric approach to computer security: how we can address a wide-spectrum of different security problems by analyzing program binaries and automatically extracting security related properties from them. In particular, I will describe the two central research directions of BitBlaze: (1) the design and development of the underlying BitBlaze Binary Analysis Platform, and (2) applying the BitBlaze Binary Analysis Platform to addressing real-world security problems, including automatic vulnerability signature generation, a unified framework for malware analysis, and automatic deviation detection.

Dawn Song is an Assistant Professor at UC Berkeley and oversees the BitBlaze binary analysis project.