io_uring Is Back, This Time as a Rootkit

This security issue gives an attacker the ability to exploit the Linux io_uring subsystem by crafting malicious submission queue entries, allowing them to evade traditional defenses. The following protection guardrails can further prevent the following steps an attacker can take: If the initial compromise or subsequent rootkit deployment occurs within a container, Container Drift Protection (Binaries & Scripts) helps prevent the execution of unauthorized tools or dropped components not present in the original image. Finally, if the installed components attempts to establish command and control by creating a reverse shell, Reverse Shell Protection detects and blocks the binding of shell input/output to a network socket. Therefore, BlueRock is not blind to io_uring-based attacks, when compared to other syscall-only based security solutions.

• T1106: Native API: The article describes a technique where attackers exploit the io_uring asynchronous I/O framework to execute arbitrary code within the kernel context. This is a clear example of exploiting an Application Programming Interface (API) to perform actions that are not intended by the legitimate functionality of the API, specifically to execute malicious code in the kernel. This aligns with the MITRE ATT&CK Technique T1106: Execution through API.
• T1068: Exploitation for Privilege Escalation: The rootkit technique allows attackers to execute code within the kernel's address space by manipulating the io_uring submission queue. This indicates that the attackers are using the legitimate processing of I/O requests to execute their code, effectively abusing the kernel's normal operations to bypass security mechanisms. This is an example of Exploitation for Privilege Escalation, where attackers exploit vulnerabilities to gain higher privileges, in this case, kernel-level execution. This aligns with the MITRE ATT&CK Technique T1068: Exploitation for Privilege Escalation.
• T1211: Exploitation for Defense Evasion: The article mentions that the rootkit circumvents common kernel security defenses such as Kernel Page Table Isolation (KPTI) or Supervisor Mode Execution Prevention (SMEP). This implies a Security Feature Bypass, where the attacker specifically targets and bypasses security mechanisms designed to prevent unauthorized code execution in the kernel. This is consistent with the MITRE ATT&CK Technique T1211: Exploitation for Defense Evasion.
• T1564: Hide Artifacts: By operating within io_uring, the rootkit can potentially hide its activities from security tools that monitor traditional system call hooks or kernel module presence. This stealth capability is indicative of the rootkit's use of techniques to avoid detection, aligning with the MITRE ATT&CK Technique T1564: Hide Artifacts, which involves concealing malicious activity from security monitoring.

F1: Basic rootkit installation and kernel code execution using io_uring manipulation.

• Attacker gains initial access to the target Linux system with privileges sufficient to interact with the io_uring subsystem (this initial access method is outside the scope of the described technique but is a prerequisite).
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of any new executable binaries or scripts (potentially used for initial access) that were not part of the original container image at load time.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because it tracks code installation via trusted package managers and blocks the execution of any new files (potentially used for initial access) added outside of these managers.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because it ensures only allow-listed privileged containers and host processes can execute new or modified files added to the host filesystem after bootup.
  • BR-80: Tainted File Download Protection - This mechanism applies if the initial access involves downloading compiled or interpreted code via tools like wget or curl and then executing it, as it blocks this specific sequence.
  • BR-88: Process Path Exec Allow - This mechanism applies by preventing the execution of initial access tools or payloads if they are placed in and run from a filesystem path not on the configured allowlist.
  • BR-90: Process Exec Deny - This mechanism applies if the initial access involves executing tools explicitly blocked by the deny list policy (e.g., processes ending in /nc, /wget, /curl).
• Attacker crafts malicious io_uring submission queue entries (SQEs). (Cited from: "manipulating the io_uring submission queue (SQ) and completion queue (CQ)", "craft malicious io_uring submission queue entries (SQEs)")
• The crafted SQEs are designed such that their processing by kernel io_uring worker threads leads to the execution of attacker-controlled code within the kernel context. (Cited from: "when processed by the kernel's io_uring worker threads, execute attacker-controlled code", "carefully setting up the SQE structure, particularly the opcode and arguments, to trigger unintended kernel operations or redirect execution flow")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable if the execution of attacker-controlled code involves hijacking indirect branches (Jump-Oriented Programming). It leverages Intel CET/IBT to enforce control-flow integrity against such attacks on CET-enabled hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable if the execution of attacker-controlled code involves hijacking return addresses (Return-Oriented Programming). It leverages Intel CET/Shadow Stack to enforce return address integrity against such attacks on CET-enabled hardware.
• The malicious SQEs are submitted to the io_uring submission queue (SQ). (Cited from: "submitting specially crafted io_uring requests")
  • BR-83: Syscall Deny Filter - This mechanism could potentially apply if a policy is configured to explicitly deny the iouringenter system call, which would prevent the submission of the malicious SQEs.
• The kernel's io_uring worker threads process the malicious SQEs from the SQ.
• Attacker achieves arbitrary code execution within the kernel's address space. (Cited from: "execute arbitrary code within the kernel context", "gains the ability to execute code within the kernel's address space")
• Using the obtained kernel code execution capability, the attacker installs rootkit components to perform malicious actions like hiding processes, files, or network connections, escalating privileges, or installing backdoors. (Cited from: "perform typical malicious actions such as hiding processes, files, or network connections, escalating privileges, or installing backdoors")
  • BR-24: File Operations Protection - This mechanism is applicable because it detects and prevents rootkit activities that involve modifying file operation data structures, often used to hide files or processes.
  • BR-30: Process Credential Protection - This mechanism is applicable because it detects and prevents unauthorized privilege escalation attempts that overwrite or redirect kernel process credentials, which the attacker might attempt after gaining kernel execution.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the rootkit installation involves modifying privileged (SUID/SGID) file inodes for persistence or privilege escalation.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and read-only data regions from unauthorized write attempts, which might occur during rootkit installation.
  • BR-39: Integrity Patch Violation - This mechanism is applicable because it detects and blocks unauthorized or malicious patch attempts to the guest kernel code, which the rootkit might use.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of any new executable binaries or scripts (rootkit components) dropped into the container after load time.
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the installed backdoor attempts to establish a reverse shell by binding shell I/O to a network socket.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the rootkit installation involves dropping new executable files onto the host filesystem outside of trusted package managers.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because it prevents non-allow-listed processes or containers from executing new or modified files (like rootkit components) added to the host filesystem after bootup.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the rootkit attempts to write to critical system directories protected by policy.
  • BR-87: Process Socket Deny - This mechanism is applicable if the rootkit components (e.g., for C2) attempt network communication and the executing process is denied socket access by policy.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the rootkit components are executed from a filesystem path not included in the configured allowlist.
  • BR-91: Sensitive File Access - This mechanism is applicable if the rootkit attempts to read or write sensitive files (like /etc/shadow, SSH keys) protected by policy.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable if the rootkit attempts to hide network connections or manipulate traffic by registering malicious Netfilter hooks.

​

F2: Bypassing modern kernel security mechanisms using io_uring for stealthy execution.

• Attacker targets systems with modern kernel security features like Kernel Page Table Isolation (KPTI) or Supervisor Mode Execution Prevention (SMEP) enabled. (Cited from: "often protected by modern security features like Kernel Page Table Isolation (KPTI) or Supervisor Mode Execution Prevention (SMEP)")
• Attacker avoids traditional rootkit techniques like modifying the system call table (syscalltable) or function pointers, which are often monitored or protected. (Cited from: "without relying on traditional methods like modifying system call tables (syscalltable) or function pointers")
• Instead, the attacker interacts with the legitimate io_uring subsystem by crafting specific SQEs. (Cited from: "operates within the legitimate io_uring framework")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable if the processing of the crafted SQE leads to an indirect branch hijack (JOP). CET/IBT aims to prevent such control-flow transfers on compatible hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable if the processing of the crafted SQE leads to a return address hijack (ROP). CET/Shadow Stack aims to prevent such control-flow transfers on compatible hardware.
  • BR-83: Syscall Deny Filter - This mechanism could potentially apply if a policy is configured to deny iouringsetup or iouringenter syscalls, preventing interaction with the subsystem.
• By manipulating the SQEs, the attacker triggers kernel code execution indirectly through the io_uring processing logic, thus circumventing checks on syscalltable integrity or direct execution attempts blocked by SMEP/KPTI. (Cited from: "circumvents common kernel security defenses designed to prevent unauthorized kernel modifications or execution", "bypasses security mechanisms")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable as it specifically complements SMEP/SMAP by preventing indirect branch hijacking (JOP) that could be used to gain execution despite memory protections. Requires CET hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable as it specifically complements SMEP/SMAP by preventing return address hijacking (ROP) that could be used to gain execution despite memory protections. Requires CET hardware.
• The rootkit's activities, channeled through io_uring operations, are potentially hidden from security tools focused on traditional system call hooks or kernel module loading. (Cited from: "By operating within io_uring, the rootkit can potentially hide its activities from security tools that monitor traditional system call hooks or kernel module presence", "Stealth")
  • BR-24: File Operations Protection - This mechanism is applicable because even if syscalls are not hooked, modifications to file operation structures for hiding files can still be detected.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it monitors kernel code and read-only data integrity, potentially detecting modifications made by the rootkit, regardless of how execution was achieved.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable because it monitors the registration of Netfilter hooks, potentially detecting network hiding attempts even if traditional syscall monitoring is bypassed.