Fork Brute Force Attack Detection/Mitigation Still Being Worked On For The Linux Kernel

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.