Fork Brute Force Attack Detection/Mitigation Still Being Worked On For The Linux Kernel
Written by Michael Larabel in Linux Security on 22 May 2021 at 05:48 AM EDT. 3 Comments
LINUX SECURITY --
A security module continues to be worked on for being able to detect and mitigate against fork/execute brute force attacks to Linux systems.

The latest iteration of patches to be able to provide brute force attack mitigation against fork/exec abuse was sent out on Friday. This seventh spin on the patches reworks some of its tracking of statistical data and other improvements. See the earlier work on this Linux Security Module (LSM) covered in Linux Patches Aim To Provide Fork'ing Brute Force Attack Mitigation.

John Wood who picked up work on these mitigation patches from Google's Kees Cook sums up this detection/mitigation as:
Attacks against vulnerable userspace applications with the purpose to break ASLR or bypass canaries traditionally use some level of brute force with the help of the fork system call. This is possible since when creating a new process using fork its memory contents are the same as those of the parent process (the process that called the fork system call). So, the attacker can test the memory infinite times to find the correct memory values or the correct memory addresses without worrying about crashing the application.

Based on the above scenario it would be nice to have this detected and mitigated, and this is the goal of this patch serie. Specifically the following attacks are expected to be detected:

1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a desirable memory layout is got (e.g. Stack Clash).
2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly until a desirable memory layout is got (e.g. what CTFs do for simple network service).
3.- Launching processes without exec() (e.g. Android Zygote) and exposing state to attack a sibling.
4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly until the previously shared memory layout of all the other children is exposed (e.g. kind of related to HeartBleed).

In each case, a privilege boundary has been crossed:

Case 1: setuid/setgid process
Case 2: network to local
Case 3: privilege changes
Case 4: network to local

So, what will really be detected are fork/exec brute force attacks that cross any of the commented bounds.

Those wanting to find out more about this pending Brute LSM can see the v7 patch series. The documentation goes well into all the interesting technical details on the Brute LSM for those interested.
Related News
About The Author
Author picture

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter or contacted via MichaelLarabel.com.

Popular News This Week