full-disclosure - Vulnerability Disclosure Debate

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87adalxr06.fsf@deneb.enyo.de>
From: fw at deneb.enyo.de (Florian Weimer)
Subject: Vulnerability Disclosure Debate

gridrun <gridrun@...es.smart-girlies.org> writes:

> The security alliance around Microsoft is trying to push its
> "reasonable vulnerability disclosure guidelines", which seeks to
> prevent security researchers from publishing proof-of-concept code
> alltogether, and wants them to make only limited, next to useless,
> information about security flaws available to the public.

Nice stance, but complete off target.  Currently, Microsoft releases
the most detailed advisories, in a consistent format, with extensive
information about possible workarounds etc.

They are pretty close to the optimum you can achieve if you want to
avoid to disclose the actual cause of the problem.

> In my humble, personal opinion, this step seeks to maximize income of
> several large security firms, as they would release any detailed
> information only to paying groups of subscribers...

This is in fact a problem.  But it is not Microsoft-specific at all.

The free software camp has adopted the responsible disclosure process
while Microsoft still was struggling with significant security issues
being reguarly publicized before they could provide countermeasures or
even investigate them.

If you think that system administrators can live without decent
security advisories as soon as they have source code, you are wrong.
Most of them lack the skills, knowledge and the time for a
source-level investigation.  Even with an isolated source code patch
(which isn't the norm, sadly), it can still be very difficult to rate
the risk for your own organization and its systems.  (For example, you
might lack the knowledge of the finer points of the protocols
involved.)

> To me, full disclosure makes perfect sense. Tell people about the
> vulnerability as soon as you notice it exists, you'll see
> "proof-of-concept" code appearing within days - essentially a proof
> that there were other people knowing about the vulnerability already.

Non sequitor.  Some people are just quick and creative, even without
early access to details.

> Also, full disclosure, including exploit code, frees you from the
> obligation to believe in software vendor advisories and patches -

Full disclosure keeps honest vendors honest, but the days of full
disclosure are over.  Almost never, the initial discoverer of a
vulnerability publishes the exploit.  For some vulnerabilities,
someone else publishes an exploit.  But you can't rely on this, you
have to establish procedures which assume only a very limited form of
disclosure.