Date: Thu, 5 Feb 2015 23:36:59 +0800 From: Shawn <citypw@...il.com> To: oss-security@...ts.openwall.com Subject: Re: Linux kernel: multiple x86_64 vulnerabilities Great analysis. Just for the record, there was a POC released for a while: https://rdot.org/forum/showthread.php?t=3341 On Tue, Feb 3, 2015 at 3:21 PM, Solar Designer <solar@...nwall.com> wrote: > On Mon, Dec 15, 2014 at 10:01:19AM -0800, Andy Lutomirski wrote: >> CVE-2014-9322: local privilege escalation, all kernel versions > > Here's Rafal Wojtczuk's writeup on exploiting it: > > http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/ > > It's been a while since Andy posted this, so I'll quote the rest of his > message for context: > >> Any kernel that is not patched against CVE-2014-9090 is vulnerable to >> privilege escalation due to incorrect handling of a #SS fault caused >> by an IRET instruction. In particular, if IRET executes on a >> writeable kernel stack (this was always the case before 3.16 and is >> sometimes the case on 3.16 and newer), the assembly function >> general_protection will execute with the user's gsbase and the >> kernel's gsbase swapped. >> >> This is likely to be easy to exploit for privilege escalation, except >> on systems with SMAP or UDEREF. On those systems, assuming that the >> mitigation works correctly, the impact of this bug may be limited to >> massive memory corruption and an eventual crash or reboot. >> >> As with CVE-2014-9090, this is fixed by: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/entry_64.S?id=6f442be2fb22be02cafa606f1769fa1e6f894441 >> >> The related fix to remove bad_iret is also an effective mitigation to >> prevent a bug like this from being reintroduced: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/entry_64.S?id=b645af2d5905c4e32399005b867987919cbfc3ae >> >> Partial credit for this bug goes to Borislav Petkov, who asked pointed >> questions about CVE-2014-9090, causing me to realize that there were >> two separate bugs in #SS handling. The first bug (CVE-2014-9090) >> caused a fatal double fault, masking the second bug that caused the >> gsbase issue. >> >> ---------- >> >> The next two bugs are related to espfix. The IRET instruction has IMO >> a blatant design flaw: IRET to a 16-bit user stack segment will leak >> bits 31:16 of the kernel stack pointer. This flaw exists on 32-bit >> and 64-bit systems. 32-bit Linux kernels have mitigated this leak for >> a long time, and 64-bit Linux kernels have mitigated this leak since >> 3.16. The mitigation is called espfix. >> >> CVE-2014-8133: espfix bypass using set_thread_area >> >> On all kernels, a valid 16-bit stack segment can be created using >> set_thread_area. Arranging to return to such a stack segment will >> bypass espfix, leaking bits 31:16 of the kernel stack pointer. Fixed >> by: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=41bdc78544b8a93a9c6814b8bbbfef966272abbe >> >> CVE-2014-8134: espfix was broken on 32-bit KVM paravirt guests >> >> espfix was completely broken on 32-bit Linux KVM guests with >> CONFIG_KVM_GUEST=y. Fixed by: >> >> https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?h=linux-next&id=29fa6825463c97e5157284db80107d1bfac5d77b >> >> This commit hasn't made it to Linus' tree yet. >> >> ---------- >> >> CVE-2014-9090 (previously announced), CVE-2014-9322, CVE-2014-8133, >> and CVE-2014-8134 can be tested by sigreturn_32, available here: >> >> https://gitorious.org/linux-test-utils/linux-clock-tests/source/10b9a7d317f6d8ae5f32bcb4bbbb186acdd6b89a >> >> Save your data before running this on a production system. If you a >> vulnerable to CVE-2014-9090 or CVE-2014-9322, the test will crash your >> system. The espfix issues will cause warnings and failures that >> mention register mismatches. >> >> -- >> Andy Lutomirski >> AMA Capital Management, LLC -- GNU powered it... GPL protect it... God blessing it... regards Shawn
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ