[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 2.6.16.5 (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.
