OS Security Is Hard: Why All the Fuzzers in the World Won't Change the Way Platform Security Is Failing Us

The last couple of years have brought exciting hardware and software security features in the top operating systems—Windows, macOS, and Linux, which have all moved toward greater integration with hypervisor, TPM, and chipset/CPU security mitigations and capabilities, while taking advantage of the compiler as well. Additionally, security teams embedded in various companies are now involved (or claim to be) in the design, implementation, and testing of such features.

Over a year ago, I presented a number of vulnerabilities in recent Windows code at a keynote in France and later in Israel, vulnerabilities which were of such simplicity that it became unclear why they had not been found through code review, fuzzing, or other tooling (because all developers write bugs). I posited that such tooling is insufficient to build truly secure systems, and that the added complexity, and reduction on the quality of training & education of developers, is leading us toward a world with more bugs, not less.

At the time, arguments were made that these were one-offs, and not all processes meant to find these types of bugs had activated yet. Multiple presentations were made on how new processes were added to fix and address future similar issues, especially when related to system calls. In this keynote, I'll review the state since last year, and show how not only were additional similar bugs added in both Dxgkrnl and Ntoskrnl, as well as how entire new security features continued to have fatal design flaws (leading to over 100K in bug bounty money due to their discovery). While these examples are Windows centric, equivalents exist in the Linux and macOS space, as this is not some sort of unique Microsoft problem.

Programmers are human, and humans make mistakes. Is automation truly the solution, or are there more fundamental changes that are needed for how we address security engineering? This keynote will make one last plea to propose changes to the engineering processes and educational priorities of future software practitioners.