Our emerging theme this week is covering security bugs in C code. But the points I want to make are less about C and more about how we use and security the apps built in C. For example, with libcurl we could talk about potential exploit scenarios and the importance of egress filters and traffic inspection -- two things unrelated to C as a programming language.
In this article, I'm worried less about anyone who's relying on the X Window System and more interested in what these flaws show us.
There are "hardening" commits along with the "fix" commits -- the devs didn't just patch the obvious flaw and move on, they considered how to make these areas of code more resilient to errors.
In one of the patches, it was cool to see that the test cases for the fix for another CVE were being run under the compiler's AddressSanitizer and, sure enough, the sanitizer identified an out-of-bounds read. This sounds like a win for leveraging the compiler's security capabilities.
In another patch, the discovery of the flaw was attributed to clang's libfuzzer. Once again, this looks like a win for compiler security options.
Appsec loves its SAST, DAST, and similar tools. It loves talking about AI. It loves talking about shifting left, as if developers never thought about security. I love seeing security capabilities in compilers and IDEs and, even better, seeing them being used and successful.