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:
- Linux x86_64 NMI security issues Andy Lutomirski (Jul 22)
- Re: Linux x86_64 NMI security issues Solar Designer (Jul 22)
- Re: Linux x86_64 NMI security issues Kurt Seifried (Jul 22)
- Re: Linux x86_64 NMI security issues Petr Matousek (Jul 23)
- Re: Linux x86_64 NMI security issues Andy Lutomirski (Jul 23)
- Re: Linux x86_64 NMI security issues Petr Matousek (Jul 23)
- Re: Linux x86_64 NMI security issues Andy Lutomirski (Jul 23)
- Re: Linux x86_64 NMI security issues Josh Boyer (Jul 24)
- Re: Linux x86_64 NMI security issues Andy Lutomirski (Jul 24)
- Re: Re: Linux x86_64 NMI security issues Luis Henriques (Jul 28)
- Re: Re: Linux x86_64 NMI security issues Thomas D. (Aug 10)
- Re: Linux x86_64 NMI security issues Andy Lutomirski (Jul 24)
- Re: Linux x86_64 NMI security issues Solar Designer (Jul 29)
- Re: Linux x86_64 NMI security issues Daniel Micay (Jul 29)
- Re: Linux x86_64 NMI security issues Jason A. Donenfeld (Aug 04)
- CVE-2015-3290: Linux privilege escalation due to nested NMIs interrupting espfix64 Andy Lutomirski (Aug 04)
- Re: Linux x86_64 NMI security issues Solar Designer (Jul 22)