[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140705193537.GA8255@openwall.com>
Date: Sat, 5 Jul 2014 23:35:37 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-4699: Linux ptrace bug
Andy, all -
On Sat, Jul 05, 2014 at 10:25:47PM +0400, Solar Designer wrote:
> "x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)"
[...]
> "CVE-2014-4699 Kernel: x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX"
BTW, I'm not convinced it's such a good idea to allow setting RIP to
exactly TASK_SIZE_MAX just because user code could run to that address
(this was Andy's rationale). Imagine that TASK_SIZE_MAX is ever set
such that it's the very first non-canonical address. If user code
simply runs to that address, it gets a user mode fault. However, if the
kernel tries to set user RIP to that address via SYSRET, it'll get #GP
while still in kernel mode - exactly the problem we're trying to fix.
So when fixing the problem in this way, or when including this as a
hardening measure along with forcing the IRET path as well, I'd prefer
to allow only "< TASK_SIZE_MAX", not "<= TASK_SIZE_MAX".
I think currently TASK_SIZE_MAX is below the first non-canonical
address, so we're fine, but there's little reason to take the risk of
possible (valid) future changes to TASK_SIZE_MAX.
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.
