Exploit published for FreeBSD local root vulnerability
Summary: The FreeBSD security team has rushed out a temporary patch to cover a local root vulnerability that exposes users to code execution attacks.
The FreeBSD security team has rushed out a temporary patch to cover a local root vulnerability that exposes users to code execution attacks. The patch follows the public release of exploit code on the Full-Disclosure mailing list.
Here's a simple explanation of the problem from "Kingcope," the hacker who released the exploit:
The bug resides in the Run-Time Link-Editor (rtld). Normally rtld does not allow dangerous environment variables like LD_PRELOAD to be set when executing setugid binaries like "ping" or "su". With a rather simple technique rtld can be tricked into accepting LD variables even on setugid binaries.
FreeBSD security officer Colin Percival confirmed the issue could allow a local user to execute arbitrary code as root. It affects FreeBSD versions 7.1 and 8.0.
Percival said FreeBSD patch is buyer-beware because it was rushed out on short notice.
Normally it is the policy of the FreeBSD Security Team to not publicly discuss security issues until an advisory is ready, but in this case since exploit code is already widely available I want to make a patch available ASAP. Due to the short timeline, it is possible that this patch will not be the final version which is provided when an advisory is sent out; it is even possible (although highly doubtful) that this patch does not fully fix the issue or introduces new issues -- in short, use at your own risk (even more than usual).
The patch is available here. See more from Threatpost's Dennis Fisher.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
But I thought
design would prevent vulnerabilities, and that
if a vulnerability was discovered that the same
superior design would make it impossible to
exploit?
Isn't that was the Unix zealots tell us all the
time?
The fact is that this bug highlights one of the
<b>worst design decisions</b> ever put into an
operating system: setuid (and setgid).
setuid allows users with execute rights on the
executable to execute <i>with the rights of the
user owning the executable</i>. If that process
drops out, experience a buffer overflow or
loads external code (a recent example of that),
the user can <b>execute as root</b> (setuid is
commonly used on "root" executables).
When that happens: Game over.
It is a mindbogglingly stupid design which was
only necessitated by the poor (coarse grained)
security in *nix where you can only control
access to file-system objects and <b>not to
system functions</b>. So, lacking this
capability, *nix'es instead come up with small
utilities which will call the privileged
functions. They will then setuid root on those
utils, hoping that they perform as designed.
The end result is that A) system admins have no
central repository for controlling or even
inspect the resultant access policies. B)
setuid utilities are dangerous in that a single
error in a single utility can open the door to
attackers.
Contrast that with operating systems which were
designed with this in mind: Windows allows
individual system functions and functional
families to be secured through <i>proper
ACLs</I>. That's right, if you don't have
access to a certain function in Windows, you
cannot execute that function through any
executable. The security is formulated per user
instead of per executable. The insecure and
error-prone setuid band-aid is not necessary.
Despite generally recognized as poor design,
this feature is repeatedly used in *nix'es,
including OS X. Simply because the granularity
of the security system (file-system based with
3-byte me-us-everyone) leaves so much to be
desired.
PS: Isn't Apple OSX based on BSD?
But Unix is older than Windows so it must be better
Nice post BTW. I find it quite hilarious how the zealots go on about how UNIX is better because... well... it is UNIX! However, support for ACLs is slowly being added, something that has been in Windows since day 1.
I haven't used ACLs in Linux for a couple years now but it was kludgy and, if I remember correctly, could [b]only[/b] be used to secure files on certain filesystems. It certainly wasn't as functional in 2007 as what was in Windows NT in 1993.
Right!
*nix is more secure - because it is *nix.
The reality is that security in *nix is a mess.
The me-us-everyone is inadequate. System
functions cannot be secured out of the box.
Instead ACls are bolted onto the top and
apparmor is bolted on to the side. Apparmor kan
be used to secure system calls, but at the
expense of a hilariously complicated
configuration and virtually no way to get a
single inspection point for what permissions a
user *really* holds (when functions are hidden
in setuid'ed utilities and all kind of tricks
must be invoked to get around the coarse
grained security).
<i>"kludgy and, if I remember correctly, could
only be used to secure files on certain
filesystems."</i>
Right. ACLs are hilariously difficult to get
right in a *nix environment. All kinds of
issues tend to creep up on the poor admins.
Which is why most still try to make do with
just me-us-everyone. And then they go online to
ridicule Windows' security design. Go figure!
Gotcha....
800.000 servers form a formidable botnet
and with beefy processors and disks.
And they are all running *nix'es, Apache and PHP.
What...the one serving malware to Windows machines?
Got it
Got it.
PS Far, far, far too many LAMP servers get hacked to dismiss the entire phenomenon due to a few incidents of password stealing.
@NonZealot..
And you need to question how those LAMP servers were hacked. Many you'll find hacked in the same manner as the rash of ASP.Net servers that were hacked a couple of summers ago. Both platforms allowed less skilled people to get code onto publicly accessible servers without much thought to security.
Wrong!!!
at all.
You sure busted them!
wonder they're so fast. It's not that they are
less bloated, they just got beefier processors!
HAH!!
No
Wrong!
get hacked, is that it would be lame if it did,
because only jerks make botnets, and all the
people who write code for Windows are good,
wholesome people. Which is why it's totally fine
for its source code to be completely hidden from
the public eye. We can all just trust it to not
have any nasty surprises.
Ya
the user to purposefully download and run the
malicious code, totally puts all UNIX-like
operating systems on the same level as Windows.
It's not like they are different operating systems
and that a problem in one doesn't occur in the
others, or like it's possible to be any less than
perfect without being as bad as Windows, right?
No, it's not, nice straw-man though.
Windows did not have ACL's at Day one...
No
Also, the only way to exploit this is by
convincing the user to download and run your
malicious code. Kind of hard to do when the norm
for releases is source rather then binaries.
Bzzzt, try again
convincing the user to download and run your
malicious code[/i]
No, you only need to convince a user to access your data in an application that has a buffer overflow flaw in it. The code was already installed on your machine.
Actually, you try again.
running on the user's computer to exploit this
vulnerability.
See, the thing is, that's harder than it sounds.
Because for it to happen, the user has to
download and run your code (or code that lets
you remotely inject your own code into it
without permission).
No, you try again
download and run your code[/i]
No, they don't need to download your code, they simply need to load up your data in their locally installed program. Like a PDF file, an OpenOffice document, an MP3, a PNG file, HTML, Flash, etc. Any buffer overflow flaw in that local program and *bang*, you are running their code.
Ya... no.
[i]"(or code that lets
you remotely inject your own code into it
without permission)"[/i]
Most MP3 players, PNG viewers, etc, don't do that.