full-disclosure - Disclosure policy in Re: RealPlayer vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: mviktora at kerio.com (Martin Viktora)
Subject: Disclosure policy in Re: RealPlayer vulnerabilities

Apparently, both Eeye Digital Research (US software security company)
and NGS Software Ltd (a UK based research firm) claim credit for 
discovering the recent vulnerability in RealPlayer. This might not 
be as interesting as the fact how the two companies decided to inform 
about the vulnerability. While NSG took responsible approach, quote:

> NGSSoftware are going to withhold details about these flaws for three
> months. Full details will be published on the 6th of January 2005. This
> three month window will allow users of RealPlayer the time needed to apply
> the patch before the details are released to the general public. This
> reflects NGSSoftware's new approach to responsible disclosure.

Eeye went ahead and released technical details about the vulnerability 
just a few days after the vendor made the patch available. Many of you 
may remember another vulnerability disclosure made by Eeye in March 2004 
when they released technical information about a flaw in ISS security 
products (ICQ parsing module) that was followed by a "zero-day-attack", when 
in 36 hours a particularly damaging ?Witty? worm struck users of ISS products
(The worm damaged users? data by writing over random hard disk sectors).

Considering the scope of RealPlayer?s vulnerability - multiple products, 
multiple target user groups (from home users to enterprises), multiple 
platforms (Windows, Mac, Linux), this early release of technical data 
about the vulnerability gives hackers again a great window of opportunity to 
attack vulnerable systems.

While I completely believe in "full disclosure" as the only way to ensure 
that software vendors take security seriously and act quickly to resolve 
security issues, even if it means that cyber criminals are given instructions 
how to write malicious code and attack, the security industry needs to 
cultivate the way how vulnerabilities are published.

Vendors often need more than the typical 30 days ultimatum given by security 
researches. Depending on the scope and nature of the vulnerability a vendor 
may need more time to test the patch and make sure that it works correctly. 
And then there is the whole issue of delivering the patch to the customers. 
Even in the ideal case when the patch can be delivered relatively quickly via 
some kind of automated update system, many companies opt to test the patch 
internally and delay its deployment (as we saw with XP SP2).

What I am calling for is that security researches take responsible approach 
in releasing information about security vulnerabilities, similar to NSG 
release policy. With zero-day-attacks, it is no longer possible that technical 
details are published about the same time the patch is made available. 
An industry accepted standard defining information release steps and time 
constrains is necessary here so that both vendors and customers are given 
enough time to make sure that they are secure before technical details 
(=instructions how to write malicious code) are released.

Martin Viktora