Unix systems give userland processes a lot of control over the what libraries get loaded dynamically into programs, so that you can (for instance) pick and choose what versions of third-party libraries you're going to use, or interpose wrapper functions over standard library functions like malloc().
This is a problem for SUID programs, because they run with higher privileges. SUID programs are supposed to be hermetically sealed. So you can't LD_PRELOAD a library into an SUID program; rtld strips the LD_* variables out of the environment.
If you create a malformed environment, the unsetenv() call rtld uses to strip the environment will fail. rtld didn't notice the failure and accepted the dangerous variables.
This flaw is a riff on one of the all-time greatest Unix localhost findings. Back on SunOS 4.1.3, the "loadmodule" program was SUID root and used system() to execute shell commands to do parts of its work. 8lgm found that if an attacker set the shell IFS variable, they could trick the Bourne shell into thinking the path seperator '/' was the token seperator ' ', and thus trick "loadmodule" into running a program out of their home directory instead of /sbin.
So Sun patched "loadmodule" to strip IFS out of the environemnt.
So 8lgm wrote a second exploit that set two IFS variables. "loadmodule" only caught the first.
If you mean the bit about 7.0 not being vulnerable, yes. The exploit code posted is slightly buggy, which is probably responsible for the false positive.
Have a non-broken mirror? The linked freebsd-announce page appears to stop loading randomly with a truncated page.
EDIT: There was a request here for clarification on why the patch worked, since unsetenv was being called on the same vars in the unpatched code. Thanks for the explanation, cperciva.
The problem is that the unsetenv function was POSIXified to make it return int when it used to return void; and then it started returning -1 when the environment was corrupt.
"Localhost vulnerability" is a meaningless term. It's called a local root exploit.
EDIT: Since I got modded down for saying this, try to Google for it. There are less than 300 hits for "localhost vulnerability," with this article leading the charge. It's simply a mistake by someone who doesn't know the terminology.
And then you clicked through and you were all, like, "dammit, I was hoping to read about a vulnerability that could only be exploited by an attacker who could already run code on the target by using sockets, but it turns out it was really about a vulnerability that could only be exploited by an attacker who could already run code on the target using the environment!", and I am very sorry for misleading you.
It could have been some weird IP spoofing attack where the host gets confused and thinks a remote connection is actually localhost and grants it some privilege or other.
For example maybe you have a ton of services setup to only listen on localhost:port. Maybe there's some exploit that allows connections from outside.
That's what the title sounds like to me, which is quite different.
I'm using the OpenBSD term, since it's what I got started with in the early 90's, when I wrote the OpenBSD advisories. It's not strictly a "root" vulnerability; if you have no SUIDs except for qmail-queue, it's a qmailq vulnerability.
I'm guessing you got downmodded because nobody cares, although being wrong couldn't have helped.
A short time ago a "local root" exploit was posted to the full-disclosure mailing list;
You don't know what you're talking about. This exploit appears to give local users root privileges, making it a local root exploit exactly as the security advisory states.
The phrase "localhost vulnerability" remains meaningless techno-babble. Localhost refers to a network address and this exploit appears to have nothing to do with that.
Ok. I'll officiate. What's the dollar amount? I recommend $100, and that the winner donate the proceeds to their preferred charity.
The bet is over when I demonstrate to you that (a) I didn't invent the term "localhost vulnerability", much as I wish I had, and (b) this vulnerability isn't strictly a "root" vulnerability. I'll withhold any further description in the interests of routing money from your bank account to a deserving charity, and I will match any dollar amount that davidw agrees to.
You mean "root exploit" not "root vulnerability." The second term is again mistaken, although it gets used a lot.
Did you even read the exploit code? He's figured out a way to overwrite LD_PRELOAD environment variable for anything SUID. That means that you get to tell the binary to load libraries other than what it planned on loading. And hence run arbitrary code.
This has nothing to do with "localhost." If you'd like to give examples of people using "localhost vulnerability" in the past, go right ahead and link to them.
This is a problem for SUID programs, because they run with higher privileges. SUID programs are supposed to be hermetically sealed. So you can't LD_PRELOAD a library into an SUID program; rtld strips the LD_* variables out of the environment.
Except, oops:
If you create a malformed environment, the unsetenv() call rtld uses to strip the environment will fail. rtld didn't notice the failure and accepted the dangerous variables.This flaw is a riff on one of the all-time greatest Unix localhost findings. Back on SunOS 4.1.3, the "loadmodule" program was SUID root and used system() to execute shell commands to do parts of its work. 8lgm found that if an attacker set the shell IFS variable, they could trick the Bourne shell into thinking the path seperator '/' was the token seperator ' ', and thus trick "loadmodule" into running a program out of their home directory instead of /sbin.
So Sun patched "loadmodule" to strip IFS out of the environemnt.
So 8lgm wrote a second exploit that set two IFS variables. "loadmodule" only caught the first.
Thanks for keeping the flame alive, FreeBSD! =)