Capsule8’s Stance on Publication and Vulnerability Disclosure

Last week, Capsule8 Labs released an exploit for the problems in systemd that Qualys identified on January 9th, as part of series analyzing the vulnerabilities CVE-2018-16865 and CVE-2018-16866. We were asked why we would “weaponize” the exploits and if it would arm those looking to do harm.  We have decided to expand on our reasoning, as it’s core to a lot of what we do here at Capsule8.

Today’s “responsible” disclosure practices do harm to end customers. Disclosure’s primary place is to be a tool to ensure vendors behave responsibly to problems in their code. It’s understandable that people want to use it to market themselves and their companies, and that’s okay too, but if vendors are behaving responsibly, then people need to be patient.

As long as vendors are acting responsibly and taking reasonable actions to fix their issues, everyone should refrain from disclosure until patches are available. The goal of the security industry should be to protect people and data, and premature disclosure in the face of a responsible vendor puts those things at risk.

Eventual disclosure is important so that people continually are reminded of the problem and the need to keep up to date with patches.  But the industry should give users a reasonable time to patch before disclosure, instead of trying to maximize the marketing impact by talking about the bug at the same time as a patch.  While 30 days is a reasonable amount of time in between upgrades, 30 seconds is not.

But whenever disclosure happens, it is incredibly important to have access to a working exploit. This systemd bug is a perfect example. Even though Qualys did not provide an exploit (citing the fact that, at the time, there was not yet a patch), it’s fairly easy for anyone with the right level of skill set to take the information they gave and produce a working exploit. Once the information is out there, the lack of an exploit is not going to be a significant hurdle for talented threat actors, who have good economic motivation to create their own exploit.

However, not having the exploit makes life harder on defenders. At Capsule8 we test our products against relevant exploits, as it helps us make sure our customers are likely to be protected against similar exploits. If this reveals any gaps, it pushes us to jump on them quickly. If we can’t test, we have to make a tough call on priorities and whether to build our own exploit to do our own testing. We hope other security vendors do the same.

End-users should be able to do the same. Defenders should have easy access to exploits in the same way attackers do, if only to test the products they use and the controls they have in place.

In short, disclosing without releasing an exploit doesn’t provide a significant speed bump to the hackers who matter (only the script kiddies). It just makes the defender’s life much harder.

So far, we have hedged our bets a bit– we have only released an exploit that requires ASLR to be turned off (even though there’s no issue landing with the bypass). Most production Linux systems will have ASLR turned on, so the exploit won’t land. This should be a high enough bar for the kiddies, but not the smart, motivated threat actor (this doesn’t concern us since the bar wasn’t unobtainable for that kind of actor anyway). But the exploit is still enough for defenders to do the testing they need to do to be able to provide some assurance to their end users.

Still, it means we haven’t “weaponized” anything, but we’ve equipped people with some ability to measure their exploit detection mechanisms.  Whether or not vulnerability researchers move towards giving longer windows for patching before disclosure, they should at least try to always provide an exploit that works well enough for the industry to test against.