glibc considers new hardening tunables to enforce ASLR for dynamic linking

Developers within the GNU C Library (glibc) project are discussing a mechanism to enhance system security by enforcing Address Space Layout Randomization (ASLR) compliance. This proposal follows a security incident in the Node.js project where a buffer overflow in the Brotli decoder became significantly more dangerous because the official Linux binaries were built without ASLR support.

If the proposed changes are implemented, administrators would gain the ability to forbid the execution of binaries that lack the necessary support for ASLR. While this provides a layer of defense against turning memory corruption bugs into remote code execution, the discussion notes that such hardening measures address the symptoms of insecure builds rather than the underlying coding errors.

Enforcing ASLR via glibc tunables

• Security Mechanism: The proposal focuses on leveraging the glibc dynamic linker to detect whether a process is running with ASLR enabled or disabled.
• Administrative Control: New tunable settings would allow system-wide or per-environment policies to reject binaries that do not support position-independent execution.
• Vulnerability Context: The motivation stems from a Node.js Brotli decoder buffer overflow where the lack of ASLR significantly lowered the barrier for potential remote code execution exploits.
• Implementation Strategy: The change would involve the dynamic linker checking for specific memory layout properties during the program startup phase.

Why it matters

Why it matters: This development would allow Linux distribution maintainers and system administrators to enforce higher security standards across their fleets. It prevents poorly built or legacy binaries from bypassing critical memory protections, though it may require developers to update build pipelines to ensure compatibility.