Date: Sat, 5 Jul 2014 22:25:47 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2014-4699: Linux ptrace bug On Fri, Jul 04, 2014 at 02:05:08PM -0700, Andy Lutomirski wrote: > Upstream commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a fixes a > ptrace bug. The exact scope of the bug is somewhat unclear right now. > I see no reason why the bug should not be present as far back as Linux > 2.6.17, but it seems to be difficult to reproduce on old kernels. Here are some distro vendor status pages on this bug: "x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1337339 Ubuntu has just sent out 7 update announcements (for different of their supported distros/kernels), USN-2266-1 through USN-2272-1. "ptrace,x86: force IRET path after a ptrace_stop()" http://kernel.opensuse.org/cgit/kernel/commit/?h=openSUSE-13.1&id=d1f26676dad578a65c94782f0c2bd00b7aa68f1b "CVE-2014-4699 Kernel: x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX" https://bugzilla.redhat.com/show_bug.cgi?id=1115927 Red Hat's statement is: "This issue affects the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2. Future kernel updates for Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2 may address this issue." but it appears to have been posted before my unsuccessful attempts to trigger the error condition on RHEL5'ish and RHEL6'ish kernels yesterday. I fully agree that we need to treat these kernels as likely vulnerable unless we can show otherwise, though - obviously, simply not being able to trigger the problem with a particular PoC doesn't mean much. So far, we're aware that the problem is definitely triggerable on recent kernels (at least mainline and recent Ubuntu) running on Intel CPUs (including in guest kernels in some VMs that run on Intel CPU hosts). Other closely related issues are CVE-2006-0744 (Linux kernel SYSRET vulnerability) and CVE-2012-0217 (Xen/FreeBSD/NetBSD/Windows SYSRET vulnerability). What we have here may be viewed as an incomplete fix for or a regression of CVE-2006-0744, depending on whether all kernels since 188.8.131.52 (the first version to have a fix for CVE-2006-0744) are vulnerable or some are not vulnerable (this is currently unclear). Due to the similarity with CVE-2012-0217, we probably could also state that the issue does not affect systems running on AMD CPUs, as that was the conclusion for CVE-2012-0217 when it was discussed two years ago. However, the fix for CVE-2006-0744 (fixed in 2006) added this comment: * When user can change the frames always force IRET. That is because * it deals with uncanonical addresses better. SYSRET has trouble * with them due to bugs in both AMD and Intel CPUs. so maybe there were in fact relevant bugs in early AMD CPUs (and this aspect was overlooked when CVE-2012-0217 was discovered and discussed?) http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ As far as I understand, for CPUs behaving as documented, the relevant difference between AMD and Intel is in whether SYSRET triggers #GP before (Intel) or after (AMD) switching to user mode. Here's its description from Intel, including pseudocode showing the problematic behavior: http://www.felixcloutier.com/x86/SYSRET.html "IF (CPL != 0) OR (RCX is not canonical) THEN #GP(0); FI;" is found close to the beginning of the SYSRET pseudocode. In my testing yesterday, I was in fact able to trigger the problem using Andy's PoC on Ubuntu 12.04.2 on Intel i7-4770K, but not on another Ubuntu 12.04.2 install on AMD FX-8120. This is as expected. 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.