Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130316033828.GA28903@openwall.com>
Date: Sat, 16 Mar 2013 07:38:28 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel race condition with PTRACE_SETREGS (CVE-2013-0871)

On Wed, Feb 20, 2013 at 01:01:25AM +0400, Solar Designer wrote:
> On Tue, Feb 19, 2013 at 12:40:50PM -0800, Julien Tinnes wrote:
> > The good news is that the race is not trivial to win in an exploit. It
> > also requires access to ptrace() (but unfortunately most distros don't
> > limit ptrace()).
> 
> Yeah.  To clarify why the vulnerability looks so bad to me: for our
> kernel builds and usage, it appears to be the worst since CVE-2010-3081
> (compat_alloc_user_space() missing sanity checks), although it is
> probably trickier to exploit in the wild (due to the race).  There were
> other local vulnerabilities in the Linux kernel discovered in those ~2.5
> years, but they were in more obscure subsystems (which we generally
> don't expose) or/and they required that the local attacker would execute
> a SUID/SGID program.  This one, however, is in an (almost) core kernel
> component and is self-contained (no dependency on the userland being
> non-perfect), which makes it almost as bad as CVE-2010-3081, except that
> it's a race.  On the other hand, CVE-2010-3081 did not affect 32-bit
> only kernel builds, whereas this new vulnerability probably does.

There's now a non-free exploit for the PTRACE_SETREGS vulnerability
(CVE-2013-0871) that is reported to work on Linux 2.6.29+ on x86_64 in
VMs (failing to win the race on bare metal?)

http://immunityproducts.blogspot.com/2013/03/immunity-releases-exploit-for-linux.html

"We do have a 32 bit version and a 2.x version which we'll finish
testing and release at some point in the near future. And we'll try to
fix the 64 bit version to work on non-VM's."

Since the (in)security community only got this far in 1 month, probably
I have somewhat overestimated the severity of this bug.  Formally, its
prerequisites are minimal and the impact is grave, but the difficult to
win race presumably happened to give a grace period of 1+ month for
everyone to patch... which, of course, most sysadmins did not do yet,
although updates from major distro vendors are now available.

Of course, it is entirely possible that more powerful exploits are
already being used privately, but I have not heard of any yet.

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.