Linux kernel -stable discussions
 help / color / mirror / Atom feed
* [PATCH] kernel: fix insecure config of eBPF generated by Kconfig
@ 2024-01-16 15:34 liboti
  2024-01-16 17:08 ` Greg KH
  2024-01-16 17:08 ` Greg KH
  0 siblings, 2 replies; 3+ messages in thread
From: liboti @ 2024-01-16 15:34 UTC (permalink / raw)
  To: ast; +Cc: shenwenbo, stable, liboti

In stable linux (4.19~5.15), if “CONFIG_BPF_SYSCALL=y” is set,
the .config generated by Kconfig does not set
“CONFIG_BPF_JIT_ALWAYS_ON” and “CONFIG_BPF_UNPRIV_DEFAULT_OFF”.
 If the kernel is compiled with such .config, a normal user
 without any capabilities at all can load eBPF programs
 (SOCKET_FILTER type), and uses the interpreter.
Due to the threat of side-channel attacks and inextirpable
mistakes in the verifier, this is considered insecure.
 We have report this issue to maintainers of architectures.
 RISCV and s390 maintainers have confirmed and advise us to
patch the Kconfig so that all architectures can be fixed.
So this patch add "default y" to these config entries.

On the other hand, we found that such configs facilitate kernel
bug exploitation. Specifically, an attacker can leverage existing
CVEs to corrupt eBPF prog-array map, hijacking a bpf_prog pointer
(ptrs[xx]) to point to a forged BPF program. In this way, arbitrary
bytecode execution can be achieved, we have proved this concept with
various CVEs(e.g. CVE-2018-18445). Such an attack enhances the
exploitability of CVEs, and is more dangerous than side-channel
threats.

Signed-off-by: liboti <hoshimi10mang@163.com>
---
 kernel/bpf/Kconfig | 91 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 kernel/bpf/Kconfig

diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
new file mode 100644
index 0000000..8abdc0d
--- /dev/null
+++ b/kernel/bpf/Kconfig
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+# BPF interpreter that, for example, classic socket filters depend on.
+config BPF
+	bool
+
+# Used by archs to tell that they support BPF JIT compiler plus which
+# flavour. Only one of the two can be selected for a specific arch since
+# eBPF JIT supersedes the cBPF JIT.
+
+# Classic BPF JIT (cBPF)
+config HAVE_CBPF_JIT
+	bool
+
+# Extended BPF JIT (eBPF)
+config HAVE_EBPF_JIT
+	bool
+
+# Used by archs to tell that they want the BPF JIT compiler enabled by
+# default for kernels that were compiled with BPF JIT support.
+config ARCH_WANT_DEFAULT_BPF_JIT
+	bool
+
+menu "BPF subsystem"
+
+config BPF_SYSCALL
+	bool "Enable bpf() system call"
+	select BPF
+	select IRQ_WORK
+	select TASKS_TRACE_RCU
+	select BINARY_PRINTF
+	select NET_SOCK_MSG if NET
+	default n
+	help
+	  Enable the bpf() system call that allows to manipulate BPF programs
+	  and maps via file descriptors.
+
+config BPF_JIT
+	bool "Enable BPF Just In Time compiler"
+	depends on BPF
+	depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
+	depends on MODULES
+	help
+	  BPF programs are normally handled by a BPF interpreter. This option
+	  allows the kernel to generate native code when a program is loaded
+	  into the kernel. This will significantly speed-up processing of BPF
+	  programs.
+
+	  Note, an admin should enable this feature changing:
+	  /proc/sys/net/core/bpf_jit_enable
+	  /proc/sys/net/core/bpf_jit_harden   (optional)
+	  /proc/sys/net/core/bpf_jit_kallsyms (optional)
+
+config BPF_JIT_ALWAYS_ON
+	bool "Permanently enable BPF JIT and remove BPF interpreter"
+	depends on BPF_SYSCALL && HAVE_EBPF_JIT && BPF_JIT
+	default y
+	help
+	  Enables BPF JIT and removes BPF interpreter to avoid speculative
+	  execution of BPF instructions by the interpreter.
+
+config BPF_JIT_DEFAULT_ON
+	def_bool ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON
+	depends on HAVE_EBPF_JIT && BPF_JIT
+
+config BPF_UNPRIV_DEFAULT_OFF
+	bool "Disable unprivileged BPF by default"
+	depends on BPF_SYSCALL
+	default y
+	help
+	  Disables unprivileged BPF by default by setting the corresponding
+	  /proc/sys/kernel/unprivileged_bpf_disabled knob to 2. An admin can
+	  still reenable it by setting it to 0 later on, or permanently
+	  disable it by setting it to 1 (from which no other transition to
+	  0 is possible anymore).
+
+source "kernel/bpf/preload/Kconfig"
+
+config BPF_LSM
+	bool "Enable BPF LSM Instrumentation"
+	depends on BPF_EVENTS
+	depends on BPF_SYSCALL
+	depends on SECURITY
+	depends on BPF_JIT
+	help
+	  Enables instrumentation of the security hooks with BPF programs for
+	  implementing dynamic MAC and Audit Policies.
+
+	  If you are unsure how to answer this question, answer N.
+
+endmenu # "BPF subsystem"
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] kernel: fix insecure config of eBPF generated by Kconfig
  2024-01-16 15:34 [PATCH] kernel: fix insecure config of eBPF generated by Kconfig liboti
@ 2024-01-16 17:08 ` Greg KH
  2024-01-16 17:08 ` Greg KH
  1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2024-01-16 17:08 UTC (permalink / raw)
  To: liboti; +Cc: ast, shenwenbo, stable

On Tue, Jan 16, 2024 at 11:34:14PM +0800, liboti wrote:
> In stable linux (4.19~5.15), if “CONFIG_BPF_SYSCALL=y” is set,
> the .config generated by Kconfig does not set
> “CONFIG_BPF_JIT_ALWAYS_ON” and “CONFIG_BPF_UNPRIV_DEFAULT_OFF”.
>  If the kernel is compiled with such .config, a normal user
>  without any capabilities at all can load eBPF programs
>  (SOCKET_FILTER type), and uses the interpreter.
> Due to the threat of side-channel attacks and inextirpable
> mistakes in the verifier, this is considered insecure.
>  We have report this issue to maintainers of architectures.
>  RISCV and s390 maintainers have confirmed and advise us to
> patch the Kconfig so that all architectures can be fixed.
> So this patch add "default y" to these config entries.
> 
> On the other hand, we found that such configs facilitate kernel
> bug exploitation. Specifically, an attacker can leverage existing
> CVEs to corrupt eBPF prog-array map, hijacking a bpf_prog pointer
> (ptrs[xx]) to point to a forged BPF program. In this way, arbitrary
> bytecode execution can be achieved, we have proved this concept with
> various CVEs(e.g. CVE-2018-18445). Such an attack enhances the
> exploitability of CVEs, and is more dangerous than side-channel
> threats.
> 
> Signed-off-by: liboti <hoshimi10mang@163.com>
> ---
>  kernel/bpf/Kconfig | 91 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
>  create mode 100644 kernel/bpf/Kconfig

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] kernel: fix insecure config of eBPF generated by Kconfig
  2024-01-16 15:34 [PATCH] kernel: fix insecure config of eBPF generated by Kconfig liboti
  2024-01-16 17:08 ` Greg KH
@ 2024-01-16 17:08 ` Greg KH
  1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2024-01-16 17:08 UTC (permalink / raw)
  To: liboti; +Cc: ast, shenwenbo, stable

On Tue, Jan 16, 2024 at 11:34:14PM +0800, liboti wrote:
> In stable linux (4.19~5.15), if “CONFIG_BPF_SYSCALL=y” is set,
> the .config generated by Kconfig does not set
> “CONFIG_BPF_JIT_ALWAYS_ON” and “CONFIG_BPF_UNPRIV_DEFAULT_OFF”.
>  If the kernel is compiled with such .config, a normal user
>  without any capabilities at all can load eBPF programs
>  (SOCKET_FILTER type), and uses the interpreter.
> Due to the threat of side-channel attacks and inextirpable
> mistakes in the verifier, this is considered insecure.
>  We have report this issue to maintainers of architectures.
>  RISCV and s390 maintainers have confirmed and advise us to
> patch the Kconfig so that all architectures can be fixed.
> So this patch add "default y" to these config entries.
> 
> On the other hand, we found that such configs facilitate kernel
> bug exploitation. Specifically, an attacker can leverage existing
> CVEs to corrupt eBPF prog-array map, hijacking a bpf_prog pointer
> (ptrs[xx]) to point to a forged BPF program. In this way, arbitrary
> bytecode execution can be achieved, we have proved this concept with
> various CVEs(e.g. CVE-2018-18445). Such an attack enhances the
> exploitability of CVEs, and is more dangerous than side-channel
> threats.
> 
> Signed-off-by: liboti <hoshimi10mang@163.com>
> ---
>  kernel/bpf/Kconfig | 91 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
>  create mode 100644 kernel/bpf/Kconfig

I don't think you tested this :(


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-01-16 17:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-16 15:34 [PATCH] kernel: fix insecure config of eBPF generated by Kconfig liboti
2024-01-16 17:08 ` Greg KH
2024-01-16 17:08 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox