Bug 1134561 - (CVE-2019-2054) VUL-0: CVE-2019-2054: kernel-source: possible seccomp bypass due to seccomp policies that allow the use of ptrace
(CVE-2019-2054)
VUL-0: CVE-2019-2054: kernel-source: possible seccomp bypass due to seccomp p...
Status: RESOLVED UPSTREAM
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/232414/
CVSSv3:SUSE:CVE-2019-2054:8.4:(AV:L/A...
:
Depends on:
Blocks: 1181039
  Show dependency treegraph
 
Reported: 2019-05-09 08:57 UTC by Alexandros Toptsoglou
Modified: 2021-01-18 07:44 UTC (History)
7 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandros Toptsoglou 2019-05-09 08:57:10 UTC
CVE-2019-2054

In the seccomp implementation prior to kernel version 4.8, there is a possible
seccomp bypass due to seccomp policies that allow the use of ptrace. This could
lead to local escalation of privilege with no additional execution privileges
needed. User interaction is not needed for exploitation. Product: Android
Versions: Android kernel Android ID: A-119769499

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-2054
http://www.cvedetails.com/cve/CVE-2019-2054/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2054
https://source.android.com/security/bulletin/2019-05-01
Comment 1 Marcus Meissner 2019-05-09 09:00:19 UTC
https://lwn.net/Articles/690685/

Kees Cook <keescook@chromium.org>
To: 	 	linux-kernel@vger.kernel.org
Subject: 	 	[PATCH 00/14] run seccomp after ptrace
Date: 	 	Thu, 9 Jun 2016 14:01:50 -0700
Message-ID: 	 	<1465506124-21866-1-git-send-email-keescook@chromium.org>
Cc: 	 	Kees Cook <keescook@chromium.org>, Andy Lutomirski <luto@kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Catalin Marinas <catalin.marinas@arm.com>, Chris Metcalf <cmetcalf@mellanox.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Helge Deller <deller@gmx.de>, "James E.J. Bottomley" <jejb@parisc-linux.org>, James Hogan <james.hogan@imgtec.com>, Jeff Dike <jdike@addtoit.com>, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, "Maciej W. Rozycki" <macro@imgtec.com>, Mark Rutland <mark.rutland@arm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Michael Ellerman <mpe@ellerman.id.au>, Paul Mackerras <paulus@samba.org>, Ralf Baechle <ralf@linux-mips.org>, Richard Weinberger <richard@nod.at>, Russell King <linux@armlinux.org.uk>, user-mode-linux-devel@lists.sourceforge.net, Will Deacon <will.deacon@arm.com>, x86@kernel.org
Archive-link: 	 	Article

There has been a long-standing (and documented) issue with seccomp
where ptrace can be used to change a syscall out from under seccomp.
This is a problem for containers and other wider seccomp filtered
environments where ptrace needs to remain available, as it allows
for an escape of the seccomp filter.

Since the ptrace attack surface is available for any allowed syscall,
moving seccomp after ptrace doesn't increase the actually available
attack surface. And this actually improves tracing since, for
example, tracers will be notified of syscall entry before seccomp
sends a SIGSYS, which makes debugging filters much easier.

The per-architecture changes do make one (hopefully small)
semantic change, which is that since ptrace comes first, it may
request a syscall be skipped. Running seccomp after this doesn't
make sense, so if ptrace wants to skip a syscall, it will bail
out early similarly to how seccomp was. This means that skipped
syscalls will not be fed through audit, though that likely means
we're actually avoiding noise this way.

This series first cleans up seccomp to remove the now unneeded
two-phase entry, fixes the SECCOMP_RET_TRACE hole (same as the
ptrace hole above), and then reorders seccomp after ptrace on
each architecture.

Thanks,

-Kees
Comment 2 Marcus Meissner 2019-05-09 09:00:50 UTC
https://www.exploit-db.com/exploits/46434

has some reference code and descriptions
Comment 3 Takashi Iwai 2019-06-12 13:29:02 UTC
The actually merged patches are 14 commits between 58d0a862f573c3354fa912603ef5a4db188774e7 and 26703c636c1f3272b39bd0f6d04d2e970984f1b6
Comment 4 Takashi Iwai 2019-06-12 15:32:33 UTC
The patchset touches and modifies the two-phase syscall entries heavily:
c87a85177e7a7f9a9ee32893fb99a928e02fe23a
8112c4f140fa03f9ee68aad2cc79afa7df5418d3

Miroslav, would you or your team can take a look at these changes?
Comment 5 Miroslav Beneš 2019-06-13 08:13:01 UTC
I could take a look for sure, but I think there may be more suitable person in our team (Boris perhaps?). Michal?
Comment 10 Marcus Meissner 2021-01-12 16:34:26 UTC
bin/addnote CVE-2019-2054 "Due to complexity and high risk backport, we currently will not backport this issue for SUSE Linux Enterprise 12 SP3 and older products. When using seccomp we recommend also to not to allow ptrace when using seccomp."