[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABniQZNx=6sdWV2n6+NkD+fdXu8DcTaBRG9UnskOmU0trOcg=A@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
