ArcaneOS - InFlux Technologies

1. Introduction

InFlux Technologies engaged Halborn to conduct a security assessment of the ArcaneOS system. Halborn was provided access to the GitHub repository and the associated internal documentation in order to conduct security testing using a combination of automated testing and manual analysis to scan, detect, validate and report possible vulnerabilities.

A comprehensive security assessment of the system identified multiple classes of vulnerabilities affecting the platform’s reliability, confidentiality, and integrity across the kernel, application, and infrastructure layers. Several findings were related to inadequate privilege separation, unsafe concurrency handling, weak cryptographic practices, insecure communication patterns, and architectural decisions that increase operational and attack surface risk.

At the kernel and low-level system layer, unsafe thread management and race conditions created conditions that could lead to Use-After-Free scenarios, memory corruption, and undefined behavior. The system employs a Unified Kernel Image (UKI), in which the kernel, initrd, and command line are bundled and cryptographically signed, providing strong protection against pre-boot tampering of these components. In addition, ArcaneOS leverages dm-verity to ensure runtime integrity of the filesystem, preventing unauthorized modification of disk contents after boot. While Secure Boot and PCR7 contribute to a trusted boot baseline, the overall boot and runtime integrity model relies on the combination of signed UKIs and dm-verity rather than PCR measurements alone. The assessment also noted that the hardware platform lacks mitigations against certain physical memory-extraction attacks, and that Trusted Execution Environments (TEEs) are not currently used to protect sensitive runtime secrets.

At the application layer, several architectural weaknesses were identified that increased the system’s attack surface. These included components running with elevated privileges, token-generation mechanisms with limited entropy designed for manual use, unsafe deserialization paths that could lead to denial-of-service conditions, and improper file-write synchronization resulting in potential configuration corruption or service instability. Information-disclosure issues—such as verbose error handling, exposure of internal secrets, and leakage of network topology—could further assist an attacker in chaining attacks.

Web-facing components exhibited additional risks, including CORS misconfigurations, insecure cookie attributes, archive-extraction logic vulnerable to Zip Slip-style path traversal, and anti-debugging mechanisms that do not provide strong security guarantees. Collectively, these issues could enable privilege escalation, denial of service, or unintended disclosure of internal system details to both local and remote adversaries.

Mitigations should focus on strengthening defenses across all layers of the stack. Recommended actions include enforcing strict least-privilege execution, improving concurrency safety, hardening token and cryptographic handling within their intended threat model, validating all external inputs, securing cookie and CORS configurations, and continuing to rely on signed UKIs and dm-verity for boot-time and runtime integrity. Where the threat model requires protection against advanced physical or runtime attacks, the optional adoption of TEEs may further reduce risk. Implementing these measures would materially improve the platform’s resilience while preserving its existing secure-by-design boot architecture.

2. Overall Recommendations

Although the use of PCR7 (Secure Boot) provided a baseline level of protection, it did not guarantee the integrity of the initrd. This introduced a single point of failure in which an attacker could compromise the boot partition and disable downstream security controls—such as watchdog mechanisms, privilege separation, and data separation—before those controls were even loaded. Furthermore, without a Trusted Execution Environment (TEE), the system remained vulnerable to runtime memory-extraction attacks.

To achieve a robust security posture, the engineering effort was required to shift toward preventative cryptographic enforcement, including extended PCR policies and the adoption of TEEs.