From: Randy Dunlap <rdunlap@infradead.org>
To: John Wood <john.wood@gmx.com>, Kees Cook <keescook@chromium.org>,
Jann Horn <jannh@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v2 7/8] Documentation: Add documentation for the Brute LSM
Date: Sun, 8 Nov 2020 20:31:13 -0800 [thread overview]
Message-ID: <2ab35578-832a-6b92-ca9b-2f7d42bc0792@infradead.org> (raw)
In-Reply-To: <20201025134540.3770-8-john.wood@gmx.com>
On 10/25/20 6:45 AM, John Wood wrote:
> Add some info detailing what is the Brute LSM, its motivation, weak
> points of existing implementations, proposed solutions, enabling,
> disabling and fine tuning.
>
> Signed-off-by: John Wood <john.wood@gmx.com>
> ---
> Documentation/admin-guide/LSM/Brute.rst | 118 ++++++++++++++++++++++++
> Documentation/admin-guide/LSM/index.rst | 1 +
> security/brute/Kconfig | 3 +-
> 3 files changed, 121 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/admin-guide/LSM/Brute.rst
>
> diff --git a/Documentation/admin-guide/LSM/Brute.rst b/Documentation/admin-guide/LSM/Brute.rst
> new file mode 100644
> index 000000000000..20c6ccbd625d
> --- /dev/null
> +++ b/Documentation/admin-guide/LSM/Brute.rst
> @@ -0,0 +1,118 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +===========================================================
> +Brute: Fork brute force attack detection and mitigation LSM
> +===========================================================
> +
> +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
traditionally
> +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 implementation.
> +
> +
> +Other implementations
> +=====================
> +
> +The public version of grsecurity, as a summary, is based on the idea of delay
delaying
> +the fork system call if a child died due to a fatal error. This has some issues:
> +
> +Bad practices
> +-------------
> +
> +Add delays to the kernel is, in general, a bad idea.
Adding
> +
> +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.
> +
> +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.
repeating
> +
> +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.
involved using
> +
> +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
consecutive
> +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
way tune
> +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.
> +
> +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
> +
> +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) -> To enable the feature
> +prctl(PR_SECURITY_FORK_BRUTE_DISABLE, 0, 0, 0, 0) -> To disable the feature
> +
> +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 an app could read crash_period_threshold and just do a new fork every
threshold + 1 time units, right? and not be caught?
thanks for the documentation.
--
~Randy
next prev parent reply other threads:[~2020-11-09 4:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-25 13:45 [PATCH v2 0/8] Fork brute force attack mitigation John Wood
2020-10-25 13:45 ` [PATCH v2 1/8] security: Add LSM hook at the point where a task gets a fatal signal John Wood
2020-10-25 13:45 ` [PATCH v2 2/8] security/brute: Define a LSM and manage statistical data John Wood
2020-10-25 13:45 ` [PATCH v2 3/8] security/brute: Add sysctl attributes to allow detection fine tuning John Wood
2020-10-25 13:45 ` [PATCH v2 4/8] security/brute: Detect a fork brute force attack John Wood
2020-10-25 13:45 ` [PATCH v2 5/8] security/brute: Mitigate " John Wood
2020-10-25 13:45 ` [PATCH v2 6/8] security/brute: Add prctls to enable/disable the fork attack detection John Wood
2020-10-25 13:45 ` [PATCH v2 7/8] Documentation: Add documentation for the Brute LSM John Wood
2020-11-09 4:31 ` Randy Dunlap [this message]
2020-11-09 18:23 ` John Wood
2020-11-10 0:09 ` Randy Dunlap
2020-10-25 13:45 ` [PATCH v2 8/8] MAINTAINERS: Add a new entry " John Wood
2020-11-06 15:54 ` [PATCH v2 0/8] Fork brute force attack mitigation John Wood
2020-11-11 0:10 ` Kees Cook
2020-11-15 15:00 ` John Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ab35578-832a-6b92-ca9b-2f7d42bc0792@infradead.org \
--to=rdunlap@infradead.org \
--cc=corbet@lwn.net \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=john.wood@gmx.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).