SLUBStick risk assessment for embedded systems August 25, 2024 | 4 min Read

SLUBStick risk assessment for embedded systems

SLUBStick risk assessment for embedded systems

The Linux kernel is susceptible to memory safety vulnerabilities due to its size and complexity. However, most of these vulnerabilities have limited capabilities, making exploitation difficult in practice. To make these vulnerabilities even more difficult to exploit, researchers and kernel developers have included defenses such as SMEP/SMAP, KASLR, and kCFI. SLUBStick, a novel kernel exploitation method that converts a limited kernel heap vulnerability into an arbitrary read-and-write primitive, making privilege escalation easier. SLUBStick operates in multiple stages, exploiting a timing side channel of the allocator to perform a cross-cache attack reliably, and then manipulating code patterns prevalent in the Linux kernel to grant arbitrary memory read and write capabilities. The defensive measures in this documentation are specifically targeted towards embedded systems, which are defined as follows:

  • Industry-specific Linux, such as aerospace (FCS/AS/GCS/Simulation), automotive (Infotainment/ADAS/TCUs/VCUs/ICs), and smart factories (Automation with PLC/Iot Gateways/Robotics/Edge computing)
  • Higher Mandatory Access Control (MAC) coverage compared to typical GNU/Linux distributions
  • Highly customized and standardized build systems
  • The patch is either delayed, incomplete, or both.

Defense & mitigation

Runtime mitigation:

  • PaX/GRsecurity is a Linux kernel security solution for large-scale deployment in high-security production environments. One of cutting-edged PaX/GRsec feature called AUTOSLAB, is an isolation-based approach to make each kalloc object have their own dedicated caches. AUTOSLAB is the only existing solution can kill off this new exploitation method. Please noted that PaX/GRsecurity requires rebuilding the kernel but it should not be a big thing since embedded system has (usually) a process with regression test, CI/CD, reproducible build system, etc.

  • VED (Vault Exploit Defense) can only mitigate the exploits targeting the specific data structure like msg_msg which likely to be the catagory of “external noise”:

alter-text

Attack surface reduction

void pin_to_core(size_t core)
{
    int ret;
    cpu_set_t cpuset;

    CPU_ZERO(&cpuset);
    CPU_SET(core, &cpuset);

    ret = sched_setaffinity(0, sizeof(cpu_set_t), &cpuset);
    if (ret)
        pr_perror("setaffinity error\n");
}

To remove the syscalls related to CPU pinning can be helpful. It may impact on some applications requires CPU affinity feature. Please noted that even with these syscalls disabled, it would only reduce the success rate from ~ 90% to ~ 70% while still requiring other measures (external noises) to reduce the success probability.

MAC (Mandatory Access Control) and non-exec partition:

  • Embedded system has higher MAC (SELinux/AppArmor/Smack/GRsecurity RBAC/etc) coverages typically. The assumption for the threat model behind SLUBStick is that the attacker possesses normal user privileges. It is crucial for the system to prevent any user from being able to “drop a binary and run it.” Certain directories, such as /run and /tmp, may permit this type of operation. Additionally, stealthy attackers may inject binaries directly into memory using a refined layout without touching the partition, which is equivalent of bypassing the read-only partition.

Recent vanilla/upstream efforts on heap mitigation

  • Separate the accounted and unaccounted caches by RedHat and SuSE merged in v5.14, making some exploits require rewrite. This feature is enabled by default for all GNU/Linux distro
  • RANDOM_KMALLOC_CACHES by Huawei, implement the multiple slab cache for each size. It’s merged in v6.6 which only a few GNU/Linux distro enabled it by default (e.g: Ubuntu 24.04).
  • Per-call-site slab caches developed by Google, merged in v6.11. It’s the infrastructure that allows Google to implement the “equivalent” of PaX/GRsecurity’s AUTOSLAB partially in the future.

Wrap-up for the defense

Building defense by studying exploitation methods is more practical and effective, because the systems always have exploitable bugs. A patch is not enough, and sometimes a patch is delayed. The PaX/GRsecurity philosophy of “Killing the entire bug classes and exploit vectors” fits well for it. For SLUBStick, either MAC and syscall-disabling are workaround for the short-term solution. When we have dived into the stage of “down to the rabbit hole” and try different approaches ended up in the same result that implementing runtime mitigations for both exploitation and post-exploitation stages becomes essential and inevitable for the long-term solution.

Performance

Based on the analysis of these features in the upstream, some do not effectively break the cycle of the whack-a-mole game and should not be enabled on embedded platforms. Unlike PCs and servers, embedded platforms are more sensitive to performance impacts. While some users may believe that the benefits of certain minor features in the vanilla/upstream kernel are necessary, implementing security measures as kernel modules (such as VED, LKRG, and AKO) provides greater flexibility, as not all nodes have the same security requirements.

Reference