GNU IFUNC: The Real Culprit Behind CVE-2024-3094

CVE-2024-3094, more commonly known as "The xz-utils backdoor," was a near miss for global cybersecurity. Had this attack not been discovered in the nick of time by Andres Freund, most of our planet's SSH servers would have begun granting root access to the party behind this attack. While much analysis has focused on how malicious code made its way into the xz-utils repository, a more fundamental issue lies in two longstanding design decisions in critical open source software: linking OpenSSH against SystemD, and the existence of GNU IFUNC.

The Supply Chain Vulnerability

The attack vector reveals a concerning architectural dependency chain in many Linux distributions:

1. Some Linux distros modify OpenSSH to depend on SystemD to fix race conditions around sshd restarts
2. SystemD depends on xz-utils for decompression
3. xz-utils uses GNU IFUNC for runtime function selection
4. This creates a situation where xz-utils code ends up in the address space of OpenSSH
5. IFUNC's design allows it to modify code in the SSH server during dynamic linking

This dependency chain exists because OpenSSH, developed by the OpenBSD community, doesn't prioritize Linux-specific needs. The Portable OpenSSH project attempts to bridge this gap, but some distributions maintain their own SystemD patches that never made it upstream due to concerns about dependencies.

The IFUNC Problem

GNU IFUNC (Indirect Function) is a feature in GCC and GNU binutils that allows developers to determine, at runtime, which version of a function should be used. It accomplishes this by allowing arbitrary code to run during symbol resolution, before the main program begins execution.

Intended Use Cases

The original purpose of IFUNC was to optimize code based on CPU features. For example, a program could check if the CPU supports AVX2 and use an optimized implementation if available, falling back to a generic version otherwise. This is demonstrated in the cpu_demo.c example provided in the repository.

However, IFUNC's design allows for more complex runtime decisions, such as determining whether output is going to a terminal or a file, as shown in tty_demo.c.

Security Implications

The fundamental issue with IFUNC is that it allows arbitrary code execution during dynamic linking, before critical security protections like RELRO (Relocation Read-Only) have been applied. This means:

• Code can execute while the Global Offset Table is still writable
• Security protections designed to protect dynamic libraries are undermined
• The principle of least astonishment is violated—loading a library shouldn't compromise security features

Implementation Difficulties

IFUNC is notoriously difficult to implement correctly:

• Documentation is sparse and misleading
• Corner cases are numerous and poorly documented
• Even years after its introduction, the advertised interface didn't work properly
• GCC developers have called it a mistake and considered adding warnings

Apple's similar feature in Mach-O (.symbol_resolver) is now "regretted" by Apple engineers, suggesting the problems aren't unique to GNU IFUNC.

Performance Analysis

While IFUNC is often justified for performance reasons, the repository's benchmark results tell a different story. The author tested three approaches:

1. Fixed implementation (baseline)
2. IFUNC-based implementation
3. Function pointer implementation

The results showed that IFUNC had approximately twice the overhead of plain function pointers when calling a simple increment function billions of times. This is significant because IFUNC's primary justification is performance optimization.

The author also tested other techniques:

• "Upfront" approach (checking CPU features once and storing results)
• "Always" approach (checking CPU features on every function call)

Surprisingly, the "always" approach was only marginally slower than IFUNC, suggesting that the performance benefits of IFUNC are minimal at best.

Alternative Approaches

Several alternatives to IFUNC exist, each with different tradeoffs:

Global Function Pointers

The simplest alternative is to use global function pointers resolved at runtime. This approach is more transparent, easier to understand, and doesn't undermine security protections like RELRO. With additional measures like mprotect(2), these pointers can also be made read-only.

LD_PRELOAD

For cases where different implementations are needed based on CPU features, LD_PRELOAD can be used to load the appropriate library at runtime. This approach requires maintaining separate libraries for different CPU feature sets but provides clear control over which implementation is used.

Separate Binaries

Shipping multiple binaries optimized for different CPU feature combinations is another viable approach. While this might seem like a combinatorial explosion, in practice CPU features don't occur independently. Most package managers support install-time logic to select the appropriate binary for the host system.

The Path Forward

The author makes a compelling case that IFUNC should be:

1. Disabled by default in GCC
2. Enabled only with explicit, scary-looking flags (e.g., --enable-cve-2024-3094)
3. Restricted to internal use within glibc, where the necessary expertise exists

Anyone using IFUNC outside of libc should be required to provide a rigorous argument that no alternative solution is appropriate.

Lessons Learned

CVE-2024-3094 highlights a fundamental issue in open source development: critical components are developed by people who don't know each other and don't communicate. This "separation of concerns" can lead to dangerous indirections where security assumptions are violated without any single team being at fault.

The attack succeeded because the attackers recognized that the left hand of Debian/Fedora SSH didn't know what the right hand of xz-utils was doing. This breakdown in communication is a feature of open source development but also creates vulnerabilities that attackers can exploit.

For more details on the technical analysis and code examples, you can explore the GitHub repository directly. The repository includes code demonstrations of IFUNC usage, performance benchmarks, and alternative implementations.

{{IMAGE:2}}

The xz-utils backdoor was a wake-up call for the software industry. While fixing the immediate vulnerability is important, addressing the architectural issues that made it possible is equally critical. GNU IFUNC represents one such architectural issue—a feature that, while well-intentioned, creates more problems than it solves in most contexts.