Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : [URGENT] FreeBSD Zero Day Exploit + Temporary Patch

[Patrick]

Hey,

For those of you who do not subscribe to the FreeBSD security mailing list, there is a public zero day exploit going around. I've been able to test it out on a few servers using different versions from FreeBSD 6.2 to FreeBSD 8.0 with mixed results. The exploit is local and requires access to the compilers along with a setugid binary. Disabling the compilers is not a valid work around and you are all strongly urged to use the following patch:

cd /usr/src/libexec/rtld-elf
fetch http://people.freebsd.org/~cperciva/rtld.patch
patch < rtld.patch
make & make install

The patch has been put out by Colin Percival, the Security Officer for the FreeBSD project.

This is what a valid exploit will look like:

%uname -a

FreeBSD domain.tld 7.2-STABLE FreeBSD 7.2-STABLE #5: Thu Nov 26 17:33:47 EST 2009 nop@domain.tld:/usr/obj/usr/src/sys/kernel i386

%whoami

nop

%sh exploit.sh

exploit.sh: gcc: Permission denied
exploit.sh: gcc: Permission denied
exploit.sh: gcc: Permission denied
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for

# whoami

root

References:

http://lists.freebsd.org/pipermail/f...er/005370.html

[Patrick]

Also, for the sake of the lazy admins out there ... please do not post any links to the exploit code. =)

[Patrick]

If the patch gives you the following output it has failed and you will need to manually apply the patch:

Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: rtld.c
|===================================================================
|--- rtld.c (revision 199977)
|+++ rtld.c (working copy)
--------------------------
Patching file rtld.c using Plan A...
Hunk #1 failed at 366.
1 out of 1 hunks failed--saving rejects to rtld.c.rej
done

Open the rtld.c file and scroll down to the following section of code:

/*
* If the process is tainted, then we un-set the dangerous environment
* variables. The process will be marked as tainted until setuid(2)
* is called. If any child process calls setuid(2) we do not want any
* future processes to honor the potentially un-safe variables.
*/
if (!trust) {
unsetenv(LD_ "PRELOAD");
unsetenv(LD_ "LIBMAP");
unsetenv(LD_ "LIBRARY_PATH");
unsetenv(LD_ "LIBMAP_DISABLE");
unsetenv(LD_ "DEBUG");
}

Replace the above code with the following and make sure you do not touch anything else or you could have a very broken system:

/*
* If the process is tainted, then we un-set the dangerous environment
* variables. The process will be marked as tainted until setuid(2)
* is called. If any child process calls setuid(2) we do not want any
* future processes to honor the potentially un-safe variables.
*/
if (!trust) {
if (unsetenv(LD_ "PRELOAD") || unsetenv(LD_ "LIBMAP") ||
unsetenv(LD_ "LIBRARY_PATH") || unsetenv(LD_ "LIBMAP_DISABLE") ||
unsetenv(LD_ "DEBUG") || unsetenv(LD_ "ELF_HINTS_PATH")) {
_rtld_error("environment corrupt; aborting");
die();
}
}

Save the file and then execute: make && make install

[CodyRo]

I'm not horribly familiar with the FBSD system (or C in general) though it looks like they allowed access to LD_PRELOAD on a SUID app (based off the original FD code).

I was impressed with the response time of FBSD, they had a patch out about an hour after it was first published to Bugtraq/FD.

[bqinternet]

I noticed that running a "make && make install" in /usr/src/libexec/rtld-elf only updates /libexec/ld-elf.so.1 on amd64 boxes, and not /libexec/ld-elf32.so.1. To be on the safe side, I then did a "make world" from /usr/src, which does update it.

[cperciva]

Originally Posted by CodyRo

I was impressed with the response time of FBSD, they had a patch out about an hour after it was first published to Bugtraq/FD.

Not quite that fast. It took me 3 hours and 15 minutes -- approximately 30 minutes before I saw the report, 90 minutes to track down what the problem was, 30 minutes to prepare the patch, 30 minutes to get a couple people to do buildworlds and confirm that it fixed the vulnerability, and 15 minutes to send the "pre-advisory" out.

[woods01]

I guess this isn't important enough to be on the FreeBSD website. Don't see anything on the advisory list.

[cperciva]

We're still working on the advisory. It should be out tomorrow.

[woods01]

lol, what a joke. Im going to have to reconsider my thoughts on FreeBSD taking security seriously.

If I was on some mailing list i'd of heard about this but the website can't be updated?

Glad you posted this here otherwise people wouldn't know about it.

[cperciva]

Originally Posted by woods01

If I was on some mailing list i'd of heard about this but the website can't be updated?

Anyone who uses FreeBSD and cares about security should be subscribed to the freebsd-security-notifications mailing list.

[bqinternet]

Originally Posted by cperciva

Anyone who uses FreeBSD and cares about security should be subscribed to the freebsd-security-notifications mailing list.

Indeed. All admins that work with FreeBSD servers should be on the list, and allow the emails to go straight to the inbox so that it's noticed right away. Better yet, have it forward to your cell phone as well.

To make it easier, subscribe here:
http://lists.freebsd.org/mailman/lis...-notifications

[woods01]

Or subscribe at www.centos.org.

I'll stop picking on FBSD now. It was my Unix of choice until this.

Maybe they just need more logos or money or something. What's an exploit here and there.

This isn't 1995, we've graduated to something a little more then email lists!

[cperciva]

Originally Posted by woods01

Maybe they just need more logos or money or something.

Well, actually, the FreeBSD Foundation could use some more money: http://www.freebsdfoundation.org/ :-)

However...

What's an exploit here and there.

... the FreeBSD Foundation, or for that matter 95% of FreeBSD developers, have no involvement in how security issues are handled. That's my (unpaid) job, and the job of the (unpaid) FreeBSD security team.

There will be an advisory for this issue RSN, at which point it will go onto the website.

This isn't 1995, we've graduated to something a little more then email lists!

I sent a "pre-advisory" email out to the mailing lists because of the unusual situation here -- we usually get notice of security issues before they become public, but in this case I wanted to get something out (most importantly, a patch) before we could get the advisory ready.

If you have ideas for how this could have been better handled, please let me know via email at security-officer@freebsd.org.

[e-Sensibility]

Originally Posted by woods01

Or subscribe at www.centos.org.

I'll stop picking on FBSD now. It was my Unix of choice until this.

Maybe they just need more logos or money or something. What's an exploit here and there.

This isn't 1995, we've graduated to something a little more then email lists!

FreeBSD is and always will be fundamentally more secure and stable than linux because of its conservative development cycle. Linux is basically a cumulative hack, and is constantly blessed and cursed with sweeping updates and bleeding edge features.

And I like how you bring CentOS up as a shining example of how an open source project should be run. I suggest you read this article and reconsider your conclusion http://www.centos.org/modules/news/a...hp?storyid=381

Considering the circumstances I think the issue was handled quickly and professionally.

[David]

Would actually like to mention I thought this was handled well -- I saw it days ago -- and I don't even have any freebsd boxes. I'm surprised you hadn't known about it.

With that said, wouldn't hurt to have twitter announcements as well: Instant, can be subscribed to via RSS and are an extremely quick way to disseminate information.