Message-ID: <20201106155423.GA4584@ubuntu>
Date:   Fri, 6 Nov 2020 16:54:23 +0100
From:   John Wood <john.wood@....com>
To:     Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>
Cc:     John Wood <john.wood@....com>, Jonathan Corbet <corbet@....net>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2 0/8] Fork brute force attack mitigation

Hi,

Has anyone had time to review this patch serie? Any comments on this?

Regards.

On Sun, Oct 25, 2020 at 02:45:32PM +0100, John Wood wrote:
> Attacks against vulnerable userspace applications with the purpose to break
> ASLR or bypass canaries traditionaly 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.
>
> Other implementations
> ---------------------
>
> The public version of grsecurity, as a summary, is based on the idea of
> delay the fork system call if a child died due to a fatal error. This has
> some issues:
>
> 1.- Bad practices: Add delays to the kernel is, in general, a bad idea.
>
> 2.- Weak points: This protection can be bypassed using two different
>     methods since it acts only when the fork is called after a child has
>     crashed.
>
>     2.1.- Bypass 1: So, it would still be possible for an attacker to fork
>           a big amount of children (in the order of thousands), then probe
>           all of them, and finally wait the protection time before repeat
>           the steps.
>
>     2.2.- Bypass 2: This method is based on the idea that the protection
>           doesn't act if the parent crashes. So, it would still be possible
>           for an attacker to fork a process and probe itself. Then, fork
>           the child process and probe itself again. This way, these steps
>           can be repeated infinite times without any mitigation.
>
> This implementation
> -------------------
>
> The main idea behind this implementation is to improve the existing ones
> focusing on the weak points annotated before. The solution for the first
> bypass method is to detect a fast crash rate instead of only one simple
> crash. For the second bypass method the solution is to detect both the
> crash of parent and child processes. Moreover, as a mitigation method it is
> better to kill all the offending tasks involve in the attack instead of use
> delays.
>
> So, the solution to the two bypass methods previously commented is to use
> some statistical data shared across all the processes that can have the
> same memory contents. Or in other words, a statistical data shared between
> all the fork hierarchy processes after an execve system call.
>
> The purpose of these statistics is to compute the application crash period
> in order to detect an attack. This crash period is the time between the
> execve system call and the first fault or the time between two consecutives
> faults, but this has a drawback. If an application crashes once quickly
> from the execve system call or crashes twice in a short period of time for
> some reason, a false positive attack will be triggered. To avoid this
> scenario the shared statistical data holds a list of the i last crashes
> timestamps and the application crash period is computed as follows:
>
> crash_period = (n_last_timestamp - n_minus_i_timestamp) / i;
>
> This ways, the size of the last crashes timestamps list allows to fine
> tuning the detection sensibility.
>
> When this crash period falls under a certain threshold there is a clear
> signal that something malicious is happening. Once detected, the mitigation
> only kills the processes that share the same statistical data and so, all
> the tasks that can have the same memory contents. This way, an attack is
> rejected.
>
> 1.- Per system enabling: This feature can be enabled at build time using
>     the CONFIG_SECURITY_FORK_BRUTE option or using the visual config
>     application under the following menu:
>
>     Security options ---> Fork brute force attack detection and mitigation
>
> 2.- Per process enabling/disabling: To allow that specific applications can
>     turn off or turn on the detection and mitigation of a fork brute force
>     attack when required, there are two new prctls.
>
>     prctl(PR_SECURITY_FORK_BRUTE_ENABLE, 0, 0, 0, 0)
>     prctl(PR_SECURITY_FORK_BRUTE_DISABLE, 0, 0, 0, 0)
>
> 3.- Fine tuning: To customize the detection's sensibility there are two new
>     sysctl attributes that allow to set the last crashes timestamps list
>     size and the application crash period threshold (in milliseconds). Both
>     are accessible through the following files respectively.
>
>     /proc/sys/kernel/brute/timestamps_list_size
>     /proc/sys/kernel/brute/crash_period_threshold
>
>     The list size allows to avoid false positives due to crashes unrelated
>     with a real attack. The period threshold sets the time limit to detect
>     an attack. And, since a fork brute force attack will be detected if the
>     application crash period falls under this threshold, the higher this
>     value, the more sensitive the detection will be.
>
> So, knowing all this information I will explain now the different patches:
>
> The 1/8 patch defines a new LSM hook to get the fatal signal of a task.
> This will be useful during the attack detection phase.
>
> The 2/8 patch defines a new LSM and manages the statistical data shared by
> all the fork hierarchy processes.
>
> The 3/8 patch adds the sysctl attributes to fine tuning the detection.
>
> Patchs 4/8 and 5/8 detect and mitigate a fork brute force attack.
>
> Patch 6/8 adds the prctls to allow per process enabling/disabling.
>
> Patch 7/8 adds the documentation to explain this implementation.
>
> Patch 8/8 updates the maintainers file.
>
> This patch series is a task of the KSPP [1] and can also be accessed from
> my github tree [2] in the "brute_v2" branch.
>
> [1] https://github.com/KSPP/linux/issues/39
> [2] https://github.com/johwood/linux/
>
> The first version can be found in:
>
> https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keescook@chromium.org/
>
> Changelog RFC -> v2
> -------------------
> - Rename this feature with a more appropiate name (Jann Horn, Kees Cook).
> - Convert the code to an LSM (Kees Cook).
> - Add locking  to avoid data races (Jann Horn).
> - Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees
>   Cook).
> - Add the last crashes timestamps list to avoid false positives in the
>   attack detection (Jann Horn).
> - Use "period" instead of "rate" (Jann Horn).
> - Other minor changes suggested (Jann Horn, Kees Cook).
>
> John Wood (8):
>   security: Add LSM hook at the point where a task gets a fatal signal
>   security/brute: Define a LSM and manage statistical data
>   security/brute: Add sysctl attributes to allow detection fine tuning
>   security/brute: Detect a fork brute force attack
>   security/brute: Mitigate a fork brute force attack
>   security/brute: Add prctls to enable/disable the fork attack detection
>   Documentation: Add documentation for the Brute LSM
>   MAINTAINERS: Add a new entry for the Brute LSM
>
>  Documentation/admin-guide/LSM/Brute.rst | 118 ++++
>  Documentation/admin-guide/LSM/index.rst |   1 +
>  MAINTAINERS                             |   7 +
>  include/brute/brute.h                   |  16 +
>  include/linux/lsm_hook_defs.h           |   1 +
>  include/linux/lsm_hooks.h               |   4 +
>  include/linux/security.h                |   4 +
>  include/uapi/linux/prctl.h              |   4 +
>  kernel/signal.c                         |   1 +
>  kernel/sys.c                            |   8 +
>  security/Kconfig                        |  11 +-
>  security/Makefile                       |   4 +
>  security/brute/Kconfig                  |  13 +
>  security/brute/Makefile                 |   2 +
>  security/brute/brute.c                  | 749 ++++++++++++++++++++++++
>  security/security.c                     |   5 +
>  16 files changed, 943 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/admin-guide/LSM/Brute.rst
>  create mode 100644 include/brute/brute.h
>  create mode 100644 security/brute/Kconfig
>  create mode 100644 security/brute/Makefile
>  create mode 100644 security/brute/brute.c
>
> --
> 2.25.1
>

Powered by blists - more mailing lists