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

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