From: Andy Lutomirski <luto@kernel.org>
To: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Jann Horn <jannh@google.com>,
Andy Lutomirski <luto@kernel.org>
Subject: [PATCH] seccomp.2: Improve x32 and nr truncation notes
Date: Fri, 10 Jul 2020 11:04:51 -0700 [thread overview]
Message-ID: <4c7e1cfa3978de83713b71a3f29c8c5f250cf0c6.1594404029.git.luto@kernel.org> (raw)
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
man2/seccomp.2 | 44 +++++++++++++++++++++++++++++++++-----------
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/man2/seccomp.2 b/man2/seccomp.2
index a1b1a28db9bf..e491825600e8 100644
--- a/man2/seccomp.2
+++ b/man2/seccomp.2
@@ -342,16 +342,38 @@ is used on the system call number to tell the two ABIs apart.
.\" an extra instruction in system_call to mask off the extra bit,
.\" so that the syscall table indexing still works.
.PP
-This means that in order to create a seccomp-based
-deny-list for system calls performed through the x86-64 ABI,
-it is necessary to not only check that
-.IR arch
-equals
-.BR AUDIT_ARCH_X86_64 ,
-but also to explicitly reject all system calls that contain
+This means that a policy must either deny all syscalls with
.BR __X32_SYSCALL_BIT
-in
-.IR nr .
+or it must recognize syscalls with and without
+.BR __X32_SYSCALL_BIT
+set. A list of syscalls to be denied based on
+.IR nr
+that does not also contain
+.IR nr
+values with
+.BR __X32_SYSCALL_BIT
+set can be bypassed by a malicious program that sets
+.BR __X32_SYSCALL_BIT .
+.PP
+Additionally, kernels prior to 5.4 incorrectly permitted
+.IR nr
+in the ranges 512-547 as well as the corresponding non-x32 syscalls ored
+with
+.BR __X32_SYSCALL_BIT .
+For example,
+.IR nr
+== 521 and
+.IR nr
+== (101 |
+.BR __X32_SYSCALL_BIT )
+would result in invocations of
+.BR ptrace (2)
+with potentially confused x32-vs-x86_64 semantics in the kernel.
+Policies intended to work on kernels before 5.4 must ensure that they
+deny or otherwise correctly handle these system calls. On kernels
+5.4 and newer, such system calls will return -ENOSYS without doing
+anything.
+.\" commit 6365b842aae4490ebfafadfc6bb27a6d3cc54757
.PP
The
.I instruction_pointer
@@ -368,8 +390,8 @@ and
system calls to prevent the program from subverting such checks.)
.PP
When checking values from
-.IR args
-against a deny-list, keep in mind that arguments are often
+.IR args,
+keep in mind that arguments are often
silently truncated before being processed, but after the seccomp check.
For example, this happens if the i386 ABI is used on an
x86-64 kernel: although the kernel will normally not look beyond
--
2.25.4
next reply other threads:[~2020-07-10 18:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 18:04 Andy Lutomirski [this message]
2020-07-24 12:16 ` [PATCH] seccomp.2: Improve x32 and nr truncation notes Michael Kerrisk (man-pages)
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=4c7e1cfa3978de83713b71a3f29c8c5f250cf0c6.1594404029.git.luto@kernel.org \
--to=luto@kernel.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.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).