Bug Disclosure Policies and the Eternal Discussion about Security ♨

In theory, there is the evolution from bug over to weakness, vulnerability and finally the exploit. Errors in code and application behaviour are interesting for any serious developer. Security researchers also look for bugs and ways to make code do something it wasn’t designed for. In the absence of critical failures in applications, the process of reporting bugs and getting them fixed everything is smooth and less prone to heated discussions (YMMV, some software projects feature persons with very strong opinions). All of this changes when the code can be remotely exploited. Enter the recent CVEs regarding the Microsoft® Exchange server. CVE-2021–26855 is as bad as it sounds. It is a remote code execution with low complexity requiring no user interaction and no privileges.

Disclosure of bugs impacting security has a long history. Knowing about vulnerabilities gives everyone an advantage. This applies both to defence and offence. The vulnerability disclosure debate rages for decades and is full of agendas. Publishing proof of concepts (PoCs) can be difficult to impossible. The recent Exchange server vulnerability is the newest example. Code showing how the vulnerability works was deleted from Github. It is still online if you want to have a look. The removal was due to Github’s acceptable use policy. Not showing the PoC does not increase protection though, because the exploit is out in the open. Not knowing now only harms the defenders. Knowing how vulnerabilities can be exploited can be used for…