From patchwork Sun Oct 25 13:45:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Wood X-Patchwork-Id: 11855381 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7FA6F61C for ; Sun, 25 Oct 2020 18:27:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55F6122269 for ; Sun, 25 Oct 2020 18:27:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=gmx.net header.i=@gmx.net header.b="gx2M5Ibx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1418053AbgJYS1O (ORCPT ); Sun, 25 Oct 2020 14:27:14 -0400 Received: from mout.gmx.net ([212.227.17.21]:44987 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1418049AbgJYS1N (ORCPT ); Sun, 25 Oct 2020 14:27:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603650413; bh=YBgtMfwJmAL5xT3k46Wa4vvB+Oniw3l18Xi6Adps7Bc=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=gx2M5IbxuA/STiTr7+7WRKOkMO76F22KonZwtZAzY+eT/R93QxuJJLRTfzOV+Z2hA FjgvcePMLYv5Spd9Jdv1pe0+tKPDUhB46iokruuFHfFaJtus9GLmErCZOY1maUlbS+ JF0KKikw7ZdX3W8kPdfxFi+RiCEeO6PEmM3v+Joc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from localhost.localdomain ([83.52.231.59]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MEm6F-1kdgTX3R3j-00GM8r; Sun, 25 Oct 2020 19:26:52 +0100 From: John Wood To: Kees Cook , Jann Horn Cc: John Wood , Jonathan Corbet , James Morris , "Serge E. Hallyn" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: [PATCH v2 7/8] Documentation: Add documentation for the Brute LSM Date: Sun, 25 Oct 2020 14:45:39 +0100 Message-Id: <20201025134540.3770-8-john.wood@gmx.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20201025134540.3770-1-john.wood@gmx.com> References: <20201025134540.3770-1-john.wood@gmx.com> MIME-Version: 1.0 X-Provags-ID: V03:K1:Cz3+eZlgwFAv6f5xHTA4nCXky6FI3BQn9S+EHC231hZb0xz0I6J +lavJK3hNxGWnTLOhuYbKVho/t2MC6+tZ4wceYFUzI9ALP6VLisk4OZzyvQymG1z7dpH6Kh ZzkSxRDlE2J91ifVTth/f/NashXwCpu9U1kENqxJ4dF4Uig3fiuVuG87PI46uJW2zYj6x0b iDJVAsK6IJ266XUmRcIyg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tmic9nfnEuk=:/Vidx7QpmAsEj70awUAUmV wsqrWv8AHeZqX9GnoXKwo2sFlzU3AHFYG/jJnLIEyf/R9meSUIaKyvQj0nCuu2sX4q9+v6lXL Vsw2MYKW3fAu6di+R1xo5SagAvqTdhOTsPLBDxnPqa6VTTZlMub3S4vTHDdh491keZ4l/MIfO yAtVtYqrqHlhFFsJJd7mDs/kzlFsDYshy7dsCqKQ62TR0DXBeJM6JXj+aNJ8IJfOn8iTCvVDA /CDVp+DOKOz3m4PxeNNdovSly97f6vwEPUzmFUqGCmTwiyqYCcFl+RBZwJNSFdJQgoP/ODaJW 4gvTK703KBWTPNnj1EM974ukzylK9M5YQnmiqvLV9/wsL6qA0CLNDmsXJS1Qfo2JiIg8HQC82 +xhmISUy/4mR/DeNJQOrsO0sHa0ISJtygLppcbfFB6KljibcrPB5QiGGrYateiqTBlD/vhaj/ xzHk8Vd/svjcHAQ4RoYBemhiRIdf0zCNxrrkiq53xl392oXP/f0URDzZDdRkxxlCVYQXugu6x 0cQRgXCGBFIKbEU4MHrY+lybYPmnyUvRZr7hxl/MHCdwdM0MR6Nj39kCBOJPldmfjk8gcd64w igecjOT3EzXbNhEI22tNjk9K0Bma01JHv66tYUJ+4TCXW58KrSXDCGxY28P1bu2rvYsbiSzRQ eyAf2iqz7Zx0ZRWOugJt29BNb1IU8AUe+fbNrJ9UAVxzdcJ2JHMMXiskczHohg/FdEHaS49O7 pQ5DJQUESQxstFbx6+SoDhQ6NCUjrS1BfluwhdcZ9ihGy3fznQ8BPzTMLHeqLBssdoL626WOk 6tPvuqCsz44kYJDG6i9pWgbuAWkE1GBjgSgec2N5ZisGhYYwkzsFBR0t/8jQ27f/tFQ7cZjhV kPtuuZ2EHpD449w06XBw== Precedence: bulk List-ID: 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 --- 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 -- 2.25.1 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 +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 +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. + +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. + +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. + +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. + diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst index a6ba95fbaa9f..1f68982bb330 100644 --- a/Documentation/admin-guide/LSM/index.rst +++ b/Documentation/admin-guide/LSM/index.rst @@ -41,6 +41,7 @@ subdirectories. :maxdepth: 1 apparmor + Brute LoadPin SELinux Smack diff --git a/security/brute/Kconfig b/security/brute/Kconfig index 1bd2df1e2dec..334d7e88d27f 100644 --- a/security/brute/Kconfig +++ b/security/brute/Kconfig @@ -7,6 +7,7 @@ config SECURITY_FORK_BRUTE vulnerable userspace processes. The detection method is based on the application crash period and as a mitigation procedure all the offending tasks are killed. Like capabilities, this security module - stacks with other LSMs. + stacks with other LSMs. Further information can be found in + Documentation/admin-guide/LSM/Brute.rst. If you are unsure how to answer this question, answer N.