Compilers Can Make Secure Code Vulnerable

Mafiscator, a compiler translating C into single machine instructions, represents just one of the specialized tools security researcher Chris Domas created to uncover deep system vulnerabilities.

His notable projects include 'Mafiscator,' a C compiler that translates code into single machine instructions, 'Sandsifter,' a CPU fuzzer designed for in-depth hardware vulnerability research, and 'Recycle,' a tool that visualizes program control flow graphs as images for reverse engineering purposes. Additionally, he developed 'Memory Sinkhole,' a method for exploiting CPUs to manipulate memory perception.

By physically overheating a processor, researchers can force a CPU to execute privileged code that is otherwise unreachable, inducing the emergency handlers known as machine check exceptions. "One way is to overheat the CPU, make it think it's about to catch on fire cuz cuz it is, and then it'll start executin," researchers noted.

Researchers can intentionally trigger these handlers, for instance, by physically overheating the CPU. This extreme measure forces the CPU to execute privileged code that would otherwise be inaccessible.

Inducing catastrophic failures in this manner can lead to severe consequences, such as causing bit flips or enabling unauthorized access to system resources.

Developers frequently assume that writing secure source code guarantees a secure resulting binary, a notion challenged by the behavior of compilers.

Compilers may remove or alter security checks and memory-clearing operations during optimization, leading to a mismatch between developer intent and the final executable's security posture. The ultimate security of the binary relies heavily on the compiler's interpretation of the C specification, which can inadvertently introduce vulnerabilities.

This adherence to a hypothetical computing environment, rather than the real CPU, dictates how code is translated and can inadvertently affect security.

Programmers commonly employ functions like `memset` or write loops to clear sensitive information, such as passwords or encryption keys, from memory.

However, compilers can analyze these operations and determine that they do not affect the final program output, subsequently deleting them. This optimization leaves sensitive data exposed in memory, despite explicit source code instructions to wipe them.

Every programming language faces the challenge of translating source code into binary instructions that a CPU can understand.

While languages like Rust offer enhanced memory safety compared to C, they still undergo a similar translation process. The researcher predicts that new languages will eventually encounter comparable compiler-related vulnerabilities as they mature and their compilers evolve.

Compiler transformations are designed to enhance code execution speed and efficiency, which are generally desirable outcomes for software performance.

These vulnerabilities are not flaws in specific compilers but rather side effects of all major compilers, such as GCC and Clang, adhering to established specifications. There is no alternative compiler that can entirely avoid these optimizations, as they are fundamental to improving code performance.

Despite the existence of compiler-related vulnerabilities, developers should avoid overreacting.

The phenomenon of compilers introducing Time-of-Check to Time-of-Use (TOCTOU) issues is a known but infrequent occurrence. Other compiler issues, such as undefined behavior and memory-clearing problems, are better understood and have existing methods for remediation.

One essential practice for developers is to enable all compiler warnings and treat them as actionable security issues requiring immediate fixes.

Utilizing sanitizers, such as AddressSanitizer and UndefinedBehaviorSanitizer, can help catch edge cases and subtle errors that might otherwise be missed. Managing the inherent gap between human-written source code and the machine code executed by the CPU remains a permanent responsibility for developers.

While compiler-introduced security flaws are rare, they can have significant impacts, especially in large codebases like the Linux kernel.

Despite these advanced vulnerabilities, adhering to secure coding practices still resolves approximately 99% of potential issues. This fundamental approach significantly reduces the attack surface for adversaries.

Attackers typically target 'low-hanging fruit,' meaning that securely written code forces them to expend much greater effort to discover and exploit vulnerabilities, thereby increasing the cost and complexity of attacks.

Developing a new, perfectly secure compiler is impractical due to the immense scale and legacy of existing projects.

Modern compilers involve millions of lines of code and have evolved over decades, resulting in extremely complex behaviors.

Compiler developers are well aware of these challenges and continuously work to address the intricate issues arising from this long evolutionary process.

The C specification explicitly permits compilers to perform transformations that can inadvertently lead to Time-of-Check to Time-of-Use (TOCTOU) vulnerabilities, even when source code appears secure.

Researchers have identified that 'register pressure' is a primary cause of this behavior, occurring when a compiler lacks available CPU registers to temporarily hold a local variable. In such cases, the compiler might discard the local 'snapshot' and instead re-read from untrusted memory, introducing a race condition.

The occurrence of certain vulnerabilities is dependent on specific 'fringe cases' within the code.

Even subtle changes, such as altering the order of fields within a C structure (struct), can influence a compiler's decision-making process, causing it to switch between generating secure and insecure binary output.

Other compiler issues, such as the deletion of security checks, are better understood and have established solutions. Both attackers and defenders face similar difficulties in identifying whether a specific binary is vulnerable due to these rare compiler behaviors.

Automated tools are essential to detect these patterns at scale, which makes manual exploitation particularly challenging for attackers.

Chris Domas acknowledged that artificial intelligence significantly simplifies the process of identifying complex vulnerability patterns.

Researchers utilized AI-driven methods to analyze code and pinpoint specific 'snapshot check use' patterns, effectively bridging the gap in automating the discovery of extremely rare, compiler-introduced flaws.

For the code analysis tasks required to pinpoint compiler-related security issues, Chris Domas noted that Claude Opus performed exceptionally well.

Current frontier AI models are generally capable of performing such analyses, and specific guidelines can further enhance their ability to understand complex security patterns.

"It's trying to find, you know, where did I write code that was not correct and how do I fix it? And that's uh at at least different enough," researchers stated.

Claude Opus demonstrated greater flexibility in collaborating on defensive remediation compared to some newer models that were more restrictive.

The ongoing development of AI guardrails remains a significant barrier, offering no guarantee that all models will support defensive security research effectively.

He advocates for pursuing questions that no one else is asking and diving into 'rabbit holes,' even if they initially appear unproductive, as this often leads to significant discoveries.