[Dailydave] Also don't read this post!

[Kees Cook]

Hi,

On Tue, Jul 28, 2009 at 04:58:24PM -0400, dave wrote:
> We had someone come in and interview today, and coincidentally I read
> this weblog post this morning:
> http://vrt-sourcefire.blogspot.com/2009/07/dont-read-this-post.html

Ubuntu published a fix for CVE-2009-0692 on Jul 14, so I assume the blog
post (published on the 22nd) was written before the 14th.  ("Me checks my
Ubuntu box for an update, not there yet, ...")

> So of course, as the "interview", he got to sit down with Bas and write
> it up. Our conclusion was that after 8.04, Ubuntu fixed their stack
> cookie and made it random (or at some point during 8.10?). The Ubuntu
> security team is on this list, so they can pipe in with when exactly[1],
> but I guess the point is this:

I noticed it during the 8.10 cycle and extracted[1] the randomization
from RedHat's monolithic glibc patch[2].  When I asked[3] them why it
wasn't upstream they said it was too much of a hack, so I set about
getting it implemented correctly[4] via the AT_RANDOM auxv.  glibc 2.9
with Linux 2.6.30 DTRT now for all distros.

I'd like to backport the fix to the earlier stable Ubuntu releases,
but it has had a lower priority due to the fact the stack overflows via
memcpy are less common (har har).

> Assuming you're not using a Gentoo which optimizes out the default GCC
> protections or say, Ubuntu 8.04 (?), which does not implement proper
> stack cookies last time we checked, is there any real risk from this
> "awesome" vulnerability?

I think all the distros either updated dhcp already or had random
stack protectors.  Also, I would expect that stack ASLR made things a
little less fun, though I haven't tried to exploit this vuln myself.
I'm curious; how did the exploit look on Ubuntu 8.04?  (Jon Oberheide's
proof-of-concept doesn't actually go about using the EIP control.)

> I haven't personally tested CentOS or Fedora or FreeBSD, but I have to
> assume they have their stack cookie done right.

Debian has no stack protector in regular builds (though I've been trying
to convince them to make it a default).  I haven't looked at FreeBSD,
but CentOS should be correct since it's effectively a fork/branch of RHEL.

Here's a question: traditionally the stack protector has been made to
start with a leading 0-byte to make str* functions unable to write to it
even if the protector value is known to the attacker.  glibc's current
implementation (with AT_RANDOM) uses all random bytes (with no leading
0 byte).  Is this a bad idea?  I think it's a bug[5].

> [1] Also please to be fixing Java Deserialize Bug!

OpenJDK was fixed when that went public.  The closed-source Java is at
the mercy of the community, and no one has made time for it, unfortunately.

-Kees

[1] http://launchpadlibrarian.net/18017811/stack-guard-quick-randomization.diff
[2] http://cvs.fedora.redhat.com/viewvc/devel/glibc/glibc-fedora.patch?revision=1.283&view=markup
[3] http://sourceware.org/ml/libc-alpha/2008-10/msg00006.html
[4] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f06295b44c296c8fb08823a3118468ae343b60f2
[5] http://sourceware.org/bugzilla/show_bug.cgi?id=10149

-- 
Kees Cook
Ubuntu Security Team