Dailydave mailing list archives
Re: Also don't read this post!
From: Kees Cook <kees () ubuntu com>
Date: Wed, 29 Jul 2009 07:47:08 -0700
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 _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Also don't read this post! dave (Jul 28)
- Re: Also don't read this post! Kees Cook (Jul 29)