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.