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 forensic analysis or creating detection rules. Furthermore, a lot of scanners already use code to determine if a server is vulnerable.
The lessons for security researchers are not new. Always use neutral platforms to publish your results, preferably your own. Stick to the facts. Bashing vendors is not full disclosure. Reporting the facts is. Proofs of concept are part of the information necessary to reproduce error conditions. Tons of scanners and security analysis tools use similar code. This is what information security is about. Showing how something breaks is essential, especially for developers.
For educational purposes, we strongly recommend having a look at the following publications.
- International Journal of Proof-of-Concept or Get The Fuck Out (PoC||GTFO or PoC or GTFO)
- Phrack
- Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea’
And please remember: Full disclosure does not mean that there must be no updates or fixes for a problem. The contrary is true.