GHSA-vjgj-42f6-7997: Protection Mechanism Failure via Incomplete Seccomp Sandbox in Netfoil

Netfoil is a minimal, filtering DNS proxy written in the Go programming language. It incorporates an optional defense-in-depth feature accessed via the --filter-system-calls command-line flag. This feature utilizes seccomp (Secure Computing mode) to apply a strict Berkeley Packet Filter (BPF) whitelist, restricting the system calls the process is permitted to execute post-initialization.

The vulnerability, tracked as GHSA-vjgj-42f6-7997, represents a Protection Mechanism Failure (CWE-693). The implementation of the seccomp filter relies on an incomplete whitelist that omits a critical system call required by the Go runtime. As a result, the application fails to establish the sandbox correctly.

When administrators attempt to harden the Netfoil deployment by enabling the --filter-system-calls flag, the application either crashes immediately upon initialization or fails silently, depending on how the error is handled downstream. This creates a state where the intended security controls are bypassed, leaving the proxy running with the full privileges of the executing user rather than the restricted seccomp profile.

The root cause of this vulnerability lies in the intersection of the Go runtime's architecture and the strict whitelist approach implemented in Netfoil's seccomp configuration. The applySystemCallFilter function is responsible for defining the array of permitted system calls before applying the BPF profile to the kernel.

The initial implementation omitted unix.SYS_RT_SIGACTION, a system call utilized by the Linux kernel to examine and alter signal actions. The Go runtime heavily depends on this specific syscall for critical internal operations, most notably garbage collection routines and goroutine preemption. The runtime must register signal handlers during execution to manage these concurrent processes effectively.

Once the seccomp filter is active, any attempt by the process to execute an unlisted syscall prompts the kernel to intervene. Because unix.SYS_RT_SIGACTION was absent from the whitelist, the Go runtime's standard operations trigger a violation. The kernel responds by sending a SIGSYS signal to the offending thread, forcing immediate termination of the process before it can process any DNS requests.

The flaw resides in the cmd/netfoil/main.go file within the applySystemCallFilter function. The vulnerable code constructs a list of allowed system calls using the golang.org/x/sys/unix package but fails to account for the signal handling requirements of the Go runtime.

The patch applied in commit 8c84f1b03adf1df5b4e6d07a49043d13dbbf9ee1 is straightforward. It modifies the whitelist array to explicitly include unix.SYS_RT_SIGACTION. This single addition satisfies the runtime's requirements while maintaining the integrity of the sandbox against unrelated syscall abuse.

// File: cmd/netfoil/main.go
// Excerpt from applySystemCallFilter
 
		unix.SYS_RT_SIGRETURN,
		unix.SYS_RT_SIGPROCMASK,
		unix.SYS_SIGALTSTACK,
+		unix.SYS_RT_SIGACTION, // Added in v0.2.1
 
		// @process
		unix.SYS_CLONE,

The execution flow and failure condition are illustrated in the architecture diagram below. In the vulnerable version, the transition from seccomp application to runtime initialization results in a fatal kernel intervention.

The primary security impact of GHSA-vjgj-42f6-7997 is the failure of an intended defense-in-depth mechanism. While this does not directly expose Netfoil to remote code execution or privilege escalation, it severely limits the application's resilience. If a separate vulnerability (such as a buffer overflow or logic flaw) were to be discovered in Netfoil's request parsing logic, the absence of the seccomp sandbox would allow an attacker full access to the underlying system's syscall interface.

Additionally, the vulnerability introduces a localized availability impact. System administrators configuring deployments with strict security baselines will experience immediate service failures when applying the --filter-system-calls flag. This denial of service occurs consistently on startup, preventing the deployment of hardened configurations.

The preliminary CVSS v3.1 vector is estimated at CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L, yielding a base score of 6.0. This score reflects the local nature of the configuration requirement and the dual impact on integrity (sandbox bypass) and availability (crash).

There are no known active exploits or weaponized proofs-of-concept for this vulnerability, as it manifests primarily as a self-inflicted denial of service or passive security degradation. The "exploitation" relies entirely on the configuration state of the application.

To reproduce the vulnerability, an administrator must compile or obtain a Netfoil binary prior to version v0.2.1 on a Linux operating system. Executing the binary with the required parameter demonstrates the failure immediately.

# Reproduction on an affected release
./netfoil --filter-system-calls

Upon execution, the terminal will output a "Bad system call" error message, and the process will exit with a non-zero status code. Analysis using standard debugging tools like strace will reveal the SIGSYS signal being delivered exactly when the runtime invokes rt_sigaction.

The official resolution for this vulnerability is to upgrade Netfoil to version v0.2.1 or later. The patch correctly implements the required system call whitelist, allowing the application to run stably while maintaining the intended seccomp sandbox boundaries.

For environments where immediate patching is not feasible, administrators must remove the --filter-system-calls flag from their startup scripts, systemd unit files, or container entrypoints. While this workaround allows the proxy to function without crashing, it explicitly acknowledges that the application will operate without seccomp protections.

Developers building Go applications with strict system call filtering must ensure they map the language runtime requirements accurately. The Go runtime abstracts many low-level OS interactions, making it critical to use dynamic tracing tools during the development phase to capture all mandatory system calls before finalizing a seccomp whitelist.