[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 08 Jul 2014 15:15:47 -0700
From: Andy Lutomirski <luto@...capital.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-4699: Linux ptrace bug
On 07/05/2014 12:35 PM, Solar Designer wrote:
> 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".
In the event that anyone changes TASK_SIZE_MAX to equal the first
non-canonical address, then this is the least of your worries: someone
can put a syscall instruction at the very last canonical address, and
game over.
This bug affected a lot of operating systems a few years ago, but AFAIK
Linux was never vulnerable.
--Andy
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.
