From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Fwd: Newly-Discovered Vulnerabilities Could Allow for Bypass of Spectre Mitigations in Linux
Date: Thu, 01 Apr 2021 20:40:17 +0200 [thread overview]
Message-ID: <1694fa63-aae3-3f50-4e43-2c03e7d7daac@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
Hello development folks,
quoted from https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/spectre-bypass-linux-vulnerabilities:
> [...] Both vulnerabilities are related to the Linux kernel support for "extended Berkeley Packet Filters" (BPF). BPF allows
> users to execute user-provided programs directly in the Linux kernel. When loading these programs, the Linux kernel analyzes
> the program code to ensure they are safe. However, part of this analysis, intended to mitigate Spectre, was not sufficient
> to protect against some exploitation techniques. [...]
>
> The most serious issue is CVE-2020-27170, which can be abused to reveal content from any location within the kernel memory,
> all of the machine’s RAM, in other words. Unprivileged BPF programs running on affected systems could bypass the Spectre
> mitigations and execute speculatively out-of-bounds loads with no restrictions. This could then be abused to reveal contents
> of the memory via side-channels. The identified security gap was that unprivileged BPF programs were allowed to perform pointer
> arithmetic on particular pointer types, where the ptr_limit was not defined. The Linux kernel did not include any protection
> against out-of-bounds speculation when performing pointer arithmetic on such pointer types.
>
> The second reported issue, CVE-2020-27171, can reveal content from a 4 GB range of kernel memory around some of the structures
> that are protected. This issue is caused by a numeric error in the Spectre mitigations when protecting pointer arithmetic
> against out-of-bounds speculations. Unprivileged BPF programs running on affected systems can exploit this error to execute
> speculatively out-of-bounds loads from a 4 GB range of kernel memory below the protected structure. Like CVE-2020-27170, this
> can also be abused to reveal contents of kernel memory via side-channels. [...]
"Don't do a JIT in the kernel", we have told them. "Don't let unprivileged users put their stuff into it", we told them.
"Don't use something volatile and hard to check - no mprotect on JITs, right? - when it comes to packet filters", we told them.
*sigh*
Since we are currently running Linux 4.14.212, while the most recent release of that branch is 4.14.228, I guess we'll have
to upgrade 4.14.x one more time. Unless Arne has 5.10.x virtually ready, resources permitting... :-)
Thanks, and best regards,
Peter Müller
reply other threads:[~2021-04-01 18:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1694fa63-aae3-3f50-4e43-2c03e7d7daac@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/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