Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ