[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150730023722.GA15205@openwall.com>
Date: Thu, 30 Jul 2015 05:37:22 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux x86_64 NMI security issues
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
