Exploit published for FreeBSD local root vulnerability

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.

SHARE:

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.

Topics: Software, Open Source, Operating Systems, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

103 comments
Log in or register to join the discussion
  • But I thought

    that Unix was impenetrable, that the superior
    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?
    honeymonster
    • But Unix is older than Windows so it must be better

      Isn't that the logic?

      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.
      NonZealot
      • Right!

        Growing tired of the mindless assertions that
        *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!
        honeymonster
        • Gotcha....

          So Windows doesn't have botnets and the servers don't get hacked because it uses ACL's. Now I undertand. ;-)
          storm14k
          • 800.000 servers form a formidable botnet

            Servers on high-bandwidth connections, always-on
            and with beefy processors and disks.

            And they are all running *nix'es, Apache and PHP.
            honeymonster
          • What...the one serving malware to Windows machines?

            ...that were accessed through stolen passwords?
            storm14k
          • Got it

            So breaking into a Unix machine by stealing a password leaves Unix blameless but convincing an end user to enter their Administrator password to install a botnet trojan on their Windows machine is all Windows' fault?

            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
          • @NonZealot..

            Its no different than the boasting I see here about ACL's in the face of an escalation threat on BSD though I still find escalation (remote at that...and not through social engineering either) vuln reports for Windows.

            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.
            storm14k
          • Wrong!!!

            Some of them got accessed by not having a password
            at all.
            AzuMao
          • You sure busted them!

            Stupid *nix'es with their beefy processors! No
            wonder they're so fast. It's not that they are
            less bloated, they just got beefier processors!
            HAH!!
            AzuMao
          • No

            Windows has botnets because people download "Flash Updates" from sites that [b]look[/b] like YouTube and then give those updates Administrator privileges when prompted.
            NonZealot
          • Wrong!

            The real reason Windows has no botnets and doesn't
            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.
            AzuMao
        • Ya

          One vulnerability found, in a *BSD, that requires
          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?
          AzuMao
      • No, it's not, nice straw-man though.

        [b] [/b]
        AzuMao
      • Windows did not have ACL's at Day one...

        Please it was DOS based and full access to the whole machine.
        mrlinux
    • No

      Just that it's not as bad as Windows.


      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.
      AzuMao
      • Bzzzt, try again

        [i]Also, the only way to exploit this is by
        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.
        NonZealot
        • Actually, you try again.

          All you need to do is have your malicious code
          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).
          AzuMao
          • No, you try again

            [i]Because for it to happen, the user has to
            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.
            NonZealot
          • Ya... no.

            Did you miss this?

            [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.
            AzuMao