Security: Security LDFLAGS disabled for NVIDIA container components

[kvinwang]

Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-42wv-fj86-jvm8 by @pbeza.

Root Cause

Both NVIDIA container components disable standard security hardening linker flags:

# nvidia-container-toolkit_1.00.bb:7
SECURITY_LDFLAGS = ""

# libnvidia-container_1.00.bb:19-20
SECURITY_LDFLAGS = ""
LDFLAGS += "-Wl,-z,lazy"

SECURITY_LDFLAGS = "" removes all Yocto-standard security flags including:

• RELRO (Relocation Read-Only): prevents GOT overwrite attacks
• BIND_NOW (immediate binding): complementary to RELRO
• Stack protector linking: links stack canary support

Additionally, LDFLAGS += "-Wl,-z,lazy" explicitly enables lazy binding, which defers symbol resolution until first use. This keeps the PLT (Procedure Linkage Table) writable at runtime, increasing the attack surface for control-flow hijacking. The security-recommended setting is immediate binding (-Wl,-z,now), which resolves all symbols at load time, allowing the PLT to be made read-only when combined with RELRO.

Attack Path

1. An attacker finds a memory corruption vulnerability in libnvidia-container or nvidia-container-toolkit
2. Without RELRO, the attacker can overwrite GOT entries to hijack control flow
3. Without stack protectors, buffer overflows are more easily exploitable
4. With lazy binding, PLT entries are writable at runtime, providing additional attack surface
5. These components run inside the CVM and handle GPU resource management

Impact

NVIDIA container components inside the CVM lack standard binary hardening. Memory corruption vulnerabilities in these components are significantly easier to exploit. These binaries have access to CVM resources and could be leveraged for privilege escalation or secret extraction.

Suggested Fix

Remove the SECURITY_LDFLAGS override and lazy binding:

# Remove these lines:
# SECURITY_LDFLAGS = ""
# LDFLAGS += "-Wl,-z,lazy"

If the build fails with standard security flags, fix the underlying compatibility issues rather than disabling security protections. File upstream issues with NVIDIA if their code is incompatible with standard hardening flags.

---

Note: This finding was reported automatically as part of an AI/Claude-driven internal audit by the NEAR One MPC team. It has not been manually verified by a human to confirm whether it constitutes an actual security issue.

[kvinwang]

Maintainer response (copied from private security advisory GHSA-42wv-fj86-jvm8):

Thanks for the report. This is a hardening observation, not a standalone vulnerability.

Disabling SECURITY_LDFLAGS and using lazy binding do not create an exploitable vulnerability on their own. They reduce defense-in-depth protections (RELRO, stack protectors, immediate binding) that only become relevant if a separate memory corruption vulnerability is first discovered in these NVIDIA components.

The SECURITY_LDFLAGS = "" is likely necessary due to compatibility issues between Go/CGo binaries and Yocto's standard security linker flags — this is a common build constraint for Go-based packages. Additionally, the CVM is a single-tenant environment, which limits the attack surface for exploitation.

We attempted to re-enable the standard security flags while keeping only -Wl,-z,lazy (required by go-nvml), but the approach did not work out (see PR #40, closed without merge). For now, the override remains necessary for build compatibility.