What If All Vulnerabilities Had This Disclosure Timeline?

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:

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.

Comments (6)

Spire Security Viewpoint | February 6, 2008 11:28 pm

<strong>The Hot Potato of Blame in the Vulnerability Game...</strong> ... (or should I say Potatoe in honor of primary season? ;-)) Chris over at Zero in a Bit has a thoughtful post on the timeline for the recent Real Player vulnerability found by Gleg. This strikes me as the type of thing we need to learn to live with. ...

CG | February 7, 2008 1:41 am

and how in all that is gleg supposed to pay the rent? it seems the days of vendors getting vulnerability information for free are over, besides a subscription to canvas isnt even close what you would pay someone with the skill to go thru and find and fix that code anyway.

asdf | February 9, 2008 4:35 am

this link http://isc.sans.org/diary.html?storyid=3810 actually mentioned old RealPlayer 11 activex exploit http://www.kb.cert.org/vuls/id/871673

Evgeny Legerov | February 9, 2008 7:17 am

my comments here - http://elegerov.blogspot.com/

none | February 9, 2008 8:34 am

CG: Your missing the point. The statement that gleg made ... "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." ... is completely absurd. With each day that gleg doesn't tell Real he puts his clients at a greater risk. His client should demand that he inform Real so that a patch can be made available to them.

Evgeny Legerov | February 10, 2008 4:41 pm

Nice to see updated post, thanks. FYI - http://elegerov.blogspot.com/2008/02/i-will-be-adding-3-absolutely-new-bugs.html

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

The content of this field is kept private and will not be shown publicly.