In November of 2014, Qualys found a severe bug in Linux’s libc.  The gethostbyname routines were subject to buffer overflow.  Qualys developed a proof of concept exploit that showed how a specially crafted email could let an attacker gain remote access to a system without any credentials.  The exploit, named GHOST, was shared with several Linux distributions who produced patches.  When Qualys  publicly announced the vulnerability, their blog page listed URLs to the distros’ patches.

Qualys says that they will publicly release their proof of concept exploit once the vulnerability has reached its half life.  According to Qualys,

Half-life is the time interval measuring a reduction of a vulnerability’s occurrence by half

Qualys does security scans on over a hundred million devices, so they can determine a vulnerability’s half life quite accurately.

Qualys’ approach offers an important contribution to the full disclosure versus responsible disclosure debate.  We can summarize the approach they took with this bug by 4 points:

1. Qualys discovered a vulnerability.
2. Qualys privately disclosed the vulnerability to affected vendors.
3. When the vendors had patches ready, Qualys publicly announced the vulnerability, and enough details that people could evaluate its severity.
4. Qualys waits until half of the end user have patched it before fully releasing details of the exploit proof of concept.

This spirit of cooperation and responsible disclosure seems far superior to a rigid 90-day rule Google uses.  Waiting until half of the end users have patched things before releasing the exploit kit also seems a gentler way of doing thing.  (However, end users must assume that criminals will work on developing exploits as soon as the existence of the vulnerability is announced.  You need to patch when the announcement is made, not when the half life is near.)

While the GHOST vulnerability was actually fixed in under 90 days, not everything can be.  If someone invent a practical quantum computer, many of the venerable security algorithms, e.g. RSA and ECC, will need to be replaced.  RFC 6916 describes how this migration could take years.  A Crypto Apocalypse simply can’t be fixed in 3 months.

As vulnerabilities are discovered, it’s in everyone’s best interest to work together to fix them.