On responsible vulnerability disclosure

- Tags: kde, security

Recently KDE had an unfortunate event. Someone found a vulnerability in the code that processes .desktop and .directory files, through which an attacker could create a malicious file that causes shell command execution (analysis). They went for immediate, full disclosure, where KDE didn't even get a chance of fixing the bug before it was published.

There are many protocols for disclosing vulnerabilities in a coordinated, responsible fashion, but the gist of them is this:

  1. Someone finds a vulnerability in some software through studying some code, or some other mechanism.

  2. They report the vulnerability to the software's author through some private channel. For free softare in particular, researchers can use Openwall's recommended process for researchers, which includes notifying the author/maintainer and distros and security groups. Free software projects can follow a well-established process.

  3. The author and reporter agree on a deadline for releasing a public report of the vulnerability, or in semi-automated systems like Google Zero, a deadline is automatically established.

  4. The author works on fixing the vulnerability.

  5. The deadline is reached; the patch has been publically released, the appropriate people have been notified, systems have been patched. If there is no patch, the author and reporter can agree on postponing the date, or the reporter can publish the vulnerability report, thus creating public pressure for a fix.

The steps above gloss over many practicalities and issues from the real world, but the idea is basically this: the author or maintainer of the software is given a chance to fix a security bug before information on the vulnerability is released to the hostile world. The idea is to keep harm from being done by not publishing unpatched vulnerabilities until there is a fix for them (... or until the deadline expires).

What happened instead

Around the beginning of July, the reporter posts about looking for bugs in KDE.

On July 30, he posts a video with the proof of concept.

On August 3, he makes a Twitter poll about what to do with the vulnerability.

On August 4, he publishes the vulnerability.

KDE is left with having to patch this in emergency mode. On August 7, KDE releases a security advisory in perfect form:

  • Description of exactly what causes the vulnerability.

  • Description of how it was solved.

  • Instructions on what to do for users of various versions of KDE libraries.

  • Links to easy-to-cherry-pick patches for distro vendors.

Now, distro vendors are, in turn, in emergency mode, as they must apply the patch, run it through QA, release their own advisories, etc.

What if this had been done with coordinated disclosure?

The bug would have been fixed, probably in the same way, but it would not be in emergency mode. KDE's advisory contains this:

Thanks to Dominik Penner for finding and documenting this issue (we wish however that he would have contacted us before making the issue public) and to David Faure for the fix.

This is an extremely gracious way of thanking the reporter.

I am not an infosec person...

... but some behaviors in the infosec sphere are deeply uncomfortable to me. I don't like it when security "research" is hard to tell from vandalism. "Excuse me, you left your car door unlocked" vs. "Hey everyone, this car is unlocked, have at it".

I don't know the details of the discourse in the infosec sphere around full disclosure against irresponsible vendors of proprietary software or services. However, KDE is free software! There is no need to be an asshole to them.