GHSA-RC6V-5RMX-W5MV: Multi-Vector Cryptographic and State Machine Vulnerabilities in Arnika

Arnika serves as a quantum-secure external extension for Wireguard VPNs, designed to implement a hybrid encryption model utilizing both Quantum Key Distribution (QKD) and Post-Quantum Cryptography (PQC). The architecture relies on an external Key Management System (KMS) for retrieving cryptographic parameters and a dedicated UDP client (udpClient) to orchestrate routine key rotations across the VPN tunnel. The system aims to augment Wireguard's inherent Noise protocol framework with additional layers of forward secrecy resistant to both classical and quantum computing attacks.

Security analysis of the Arnika codebase revealed three distinct vulnerabilities in the components managing these cryptographic extensions. The first vulnerability involves the udpClient state machine, which fails to validate temporal indicators during the key rotation acknowledgment phase. The second issue resides in the local configuration parser, which permits the loading of truncated or insecurely permissioned PQC Pre-Shared Key (PSK) files. The third vulnerability is a direct configuration error in the KMS client, explicitly disabling Transport Layer Security (TLS) certificate validation.

These flaws compromise the integrity, availability, and confidentiality guarantees of the Arnika extension. The combination of local state manipulation and network-level interception surfaces allows an adversary to systematically dismantle the hybrid security model. Exploitation requires specific network positioning or local access, categorizing the issues as medium severity.

All three vulnerabilities are tracked collectively under the advisory GHSA-RC6V-5RMX-W5MV. The maintenance team addressed these issues in release v1.0.1, introducing strict file validation routines, mandatory explicit length checks prior to key derivation, and enforced TLS certificate verification.

The udpClient component manages the continuous rotation of cryptographic keys between the Arnika client and the VPN server. This process relies on a state machine that transitions through distinct phases: initiation, key request, acknowledgment, and finalization. The transition from the acknowledgment phase relies on the receipt of an acknowledgment packet (ackPkt) over a connectionless UDP socket.

The vulnerability stems from the absence of validation on the Timestamp field within the ackPkt structure. When the client receives an acknowledgment packet, the parsing logic extracts the routing and state data but ignores the temporal metadata indicating when the packet was generated. The state machine unconditionally accepts the packet and updates its internal pointer based solely on the structural validity of the UDP payload.

This architectural oversight introduces a CWE-294 (Authentication Bypass by Capture-replay) vulnerability. An adversary positioned to intercept traffic between the client and the server can capture a legitimate ackPkt during an active session. Because the protocol relies on UDP, which provides no inherent sequencing or session integrity, the captured packet remains structurally valid indefinitely from the client's perspective.

When the adversary injects the captured ackPkt during a subsequent key rotation cycle, the client processes the replayed packet and alters its state machine based on the historical data. The server, meanwhile, progresses normally. This divergence causes a permanent desynchronization of the tunnel keys, resulting in a persistent Denial of Service (DoS) for the specific Wireguard endpoint until the service is manually restarted.

The Arnika hybrid encryption model derives its final tunnel keys by passing both QKD material and a PQC Pre-Shared Key through a Hash-based Key Derivation Function (HKDF). The local configuration parser in config/config.go is responsible for loading the PQC PSK from the filesystem. The logic utilizes os.Stat to verify the existence of the file, checking strictly against os.IsNotExist(err) before proceeding to read the contents.

The implementation fails to check the size of the targeted file. If the file is entirely empty, the standard Go library function os.ReadFile returns an empty byte slice without generating an error. The subsequent processing pipeline passes this empty byte slice to the Base64 decoding routine. The Go Base64 decoder correctly processes an empty input by returning another empty byte slice, again without raising an error condition.

In main.go, the application passes this zero-length slice into the HKDF implementation alongside the QKD-derived key. The HKDF specification (RFC 5869) accepts zero-length input keying material, effectively functioning as an identity operation for that specific input parameter. Consequently, the final derived key is generated utilizing only the entropy from the QKD material, silently bypassing the intended hybrid security model and reverting to a single-factor encryption scheme.

Furthermore, the original implementation lacks explicit file permission validation. The system loads the PQC PSK regardless of the underlying POSIX permissions, permitting the use of key files that are group-readable or world-readable. This CWE-732 (Incorrect Permission Assignment) vulnerability allows unauthorized local users to extract the cryptographic material, fully compromising the PQC layer of the hybrid encryption model.

The Key Management System (KMS) client acts as the authoritative source for retrieving external cryptographic parameters required by the Arnika extension. This communication occurs over HTTPS, relying on the Go standard library crypto/tls package to ensure transport security. The integrity of the key distribution mechanism depends entirely on the robust validation of the server's identity during the TLS handshake.

The initialization code for the KMS client instantiates a tls.Config struct to manage the connection parameters. Within this instantiation, the InsecureSkipVerify boolean is explicitly set to true. This configuration instructs the TLS client to completely bypass the validation of the server's x509 certificate chain and the verification of the host name against the certificate's Subject Alternative Name (SAN).

Disabling certificate verification nullifies the primary defense mechanism against active interception, introducing a severe CWE-295 (Improper Certificate Validation) vulnerability. The client will establish a secure channel with any entity that presents a structurally valid TLS response, regardless of whether that entity possesses a certificate signed by a trusted Certificate Authority.

An adversary with the ability to route or intercept traffic directed at the KMS can terminate the TLS connection and present a self-signed certificate. The Arnika client will accept this connection and proceed to request or exchange key material. The adversary can then read, modify, or inject fraudulent cryptographic parameters into the Arnika system, completely compromising the confidentiality and integrity of the VPN tunnel.

The initial vulnerable implementation of the TLS configuration and configuration parsing demonstrated fundamental gaps in security validation. The code explicitly disabled verification and failed to analyze file metadata.

// Vulnerable KMS TLS Configuration
tlsConfig := &tls.Config{
    InsecureSkipVerify: true, 
    RootCAs:            caCertPool,
}
 
// Vulnerable PQC PSK Loading in config.go
if _, err := os.Stat(config.PQCPSKFile); os.IsNotExist(err) {
    return nil, fmt.Errorf("[ERROR] failed to open PQC PSK file: %w", err)
}

The remediation implemented in commit efbd980d8b636cb59f60f2d6ece1b80a9cf36535 addresses these issues by enforcing strict validation criteria. The InsecureSkipVerify assignment is removed entirely from the TLS configuration. The configuration parser now requires the file size to be greater than zero and restricts the POSIX permissions to limit access exclusively to the owner.

// Patched PQC PSK Loading in config.go
stat, err := os.Stat(config.PQCPSKFile)
if os.IsNotExist(err) {
    return nil, fmt.Errorf("[ERROR] failed to open PQC PSK file: %w", err)
}
if stat.Size() == 0 {
    return nil, fmt.Errorf("[ERROR] PQC PSK file is empty")
}
if stat.Mode()&0077 != 0 {
    return nil, fmt.Errorf("[ERROR] insecure permissions on PQC PSK file")
}

While the patch successfully mitigates the silent downgrade issue, architectural analysis reveals a Time-of-Check to Time-of-Use (TOCTOU) vulnerability. The code utilizes os.Stat to validate the file metadata, but the actual file contents are accessed subsequently via a separate system call (os.ReadFile). An attacker with write privileges to the containing directory could potentially swap the valid file for a malicious symlink or an empty file in the brief window between the stat check and the read operation. A more robust implementation would involve opening a file descriptor first and executing fstat on the open handle to ensure the validated metadata corresponds to the data being read.

Exploiting the UDP key-rotation vulnerability requires an adversary to establish a Man-in-the-Middle (MITM) position between the Arnika client and the server. The attacker utilizes packet capture tools to passively monitor the UDP traffic and isolate an acknowledgment packet (ackPkt) originating from the server. Once captured, the attacker injects this payload during a subsequent key rotation phase. The client processes the invalid timestamp, resulting in immediate state desynchronization and a loss of tunnel connectivity.

The cryptographic downgrade attack requires local access to the filesystem hosting the Arnika configuration. An adversary lacking root privileges but possessing write access to the configuration directory can execute a simple truncation command (e.g., truncate -s 0 /path/to/pqc.key). When the Arnika service restarts or reloads its configuration, it ingests the empty file. The HKDF process derives the session key using only the QKD material, nullifying the quantum-resistant properties of the hybrid system.

Exploitation of the KMS TLS vulnerability involves intercepting the HTTPS traffic destined for the Key Management System. The attacker performs DNS spoofing or ARP poisoning to redirect the client's requests to a malicious proxy infrastructure. The proxy presents a self-signed TLS certificate, which the vulnerable Arnika client accepts due to the InsecureSkipVerify directive. The proxy then logs the key exchange parameters or injects deterministic keys into the client.

These attack vectors operate independently but can be chained by an advanced persistent threat. An attacker could force a cryptographic downgrade via local file manipulation, intercept the KMS traffic to compromise the remaining QKD keys, and utilize UDP replay to disrupt operations or force re-authentication cycles.

The primary remediation for these vulnerabilities is an immediate upgrade to Arnika version 1.0.1. This release contains the necessary structural changes to enforce strict file validation, explicitly check key lengths before derivation, and mandate standard TLS certificate verification against the system's root trust store. System administrators should orchestrate this deployment across all VPN nodes to ensure uniform security enforcement.

For environments where immediate upgrading is not feasible, administrators must implement compensating controls at the operating system level. The PQC PSK file permissions must be manually audited and locked down. Executing chmod 0600 on the key files and verifying ownership ensures that unprivileged local users cannot read or truncate the cryptographic material. Furthermore, file integrity monitoring solutions should be deployed to alert on unauthorized modifications to the configuration directory.

Network-level mitigations are required to defend against the UDP replay and KMS MITM vulnerabilities in unpatched systems. Implementing strict network segmentation ensures that KMS management traffic is isolated to dedicated administration VLANs, reducing the attack surface for local interception. Deploying intrusion detection signatures to monitor for anomalous UDP key-rotation patterns can provide early warning of active replay attempts.

To address the residual TOCTOU vulnerability identified during the patch analysis, developers should revise the file handling logic in future iterations. Implementing atomic file operations, utilizing open file descriptors for metadata validation, and relying on strict directory permissions will eliminate the race condition window. Incorporating these practices ensures the robustness of the cryptographic pipeline against concurrent local attacks.