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

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