oss-sec mailing list archives

Re: Linux x86_64 NMI security issues


From: Solar Designer <solar () openwall com>
Date: Thu, 30 Jul 2015 05:37:22 +0300

On Wed, Jul 22, 2015 at 11:12:00AM -0700, Andy Lutomirski wrote:
+++++ CVE-2015-5157 +++++
[...]
Mitigations: Use seccomp to disable perf_event_open or modify_ldt or
run with only a single CPU.  To my knowledge, this cannot be exploited
on single-processor systems or in single-threaded applications.
[...]
+++++ CVE-2015-3290 +++++

High impact NMI bug on x86_64 systems 3.13 and newer, embargoed.  Also fixed by:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a

The other fix (synchronous modify_ldt) does *not* fix CVE-2015-3290.

You can mitigate CVE-2015-3290 by blocking modify_ldt or
perf_event_open using seccomp.  A fully-functional, portable, reliable
exploit is privately available and will be published in a week or two.
*Patch your systems*

I understand how seccomp is usable for sandboxing in a program, but how
would a sysadmin block syscalls with it?

Perhaps we still need a new interface that would enable a sysadmin to
easily block individual syscalls?  The idea of blocking modify_ldt for
the entire system was brought up before:

http://www.openwall.com/lists/kernel-hardening/2011/06/19/2
http://www.openwall.com/lists/owl-dev/2012/08/05/2

even though there are valid reasons for having it available to all, e.g.:

http://www.openwall.com/lists/musl/2014/06/10/1

Past issues with and thoughts on the ability for user processes to
modify the LDT, dating back to 2001:

http://marc.info/?l=linux-security-audit&m=98237041708897

BTW, Red Hat now has a statement here:

https://access.redhat.com/security/cve/CVE-2015-3290

"This issue does not affect the Linux kernel packages as shipped with
Red Hat Enterprise Linux 5 and 6 since they did not backport the nested
NMI handler and espfix64 functionalities.

This issue does not affect the Linux kernel packages as shipped with Red
Hat Enterprise Linux 7 and Red Hat Enterprise MRG 2 since they did not
backport the espfix64 functionality and also did not backport upstream
commit e00b12e64be9a3 that allowed an unprivileged local user to
re-enable NMIs from the NMI handler."

The mentioned commit is:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e00b12e64be9a3

Alexander


Current thread: