Slashdot Mirror

← Back to Stories (view on slashdot.org)

Local Root Vulnerability in passwd(1) on Solaris 8, 9

Posted by CowboyNeal on from the heads-up dept.

so-1997-and-1994 writes "There is a new vulnerability in the passwd command on solaris 8 and 9. Looks like a local user privilege escalation is possible. Patch your systems. This not the first nor the last time something like this has shown up."

44 of 283 comments (clear)

  1. There but for the Grace of God go I by Space+cowboy · · Score: 4, Interesting

    So there's no workaround and no symptoms of it having been used. Ouch. Essentially if you want to be certain that a multi-user system has not been hacked, you need to reinstall the operating system from scratch, formatting all the disks...

    So, what are the chances of it happening on Linux ? Well, probably less (the many-eyes scenario), but certainly possible. This isn't a time to be smug about not running Solaris...

    Simon

    --
    Physicists get Hadrons!
    1. Re:There but for the Grace of God go I by Avian+visitor · · Score: 5, Insightful

      Essentially if you want to be certain that a multi-user system has not been hacked, you need to reinstall the operating system from scratch, formatting all the disks...

      Each time a new local/remote root vulnerability is found the only way to be certain you haven't been cracked is to reinstall from scratch.

      Even if this vulnerability would cause some log messages or other symptoms an attacker with root privileges could easily erase them.

    2. Re:There but for the Grace of God go I by kryps · · Score: 5, Insightful

      "So there's no workaround..."
      No, there are patches.

      "... and no symptoms of it having been used."
      As a previous poster pointed out, traces left by any root exploit can be removed once the attacker is root (unless you redirect syslog to a printer or another "secure" machine) and it is not really rare for a root exploit to leave not trace (I don't know if the recet Linux kernel mremap exploits left any).

      "So, what are the chances of it happening on Linux ? Well, probably less (the many-eyes scenario), but certainly possible. This isn't a time to be smug about not running Solaris..."
      What the f**k are you talking about? Most recently there was the mremap local root exploit which affected 2.4 and 2.6 Linux kernels. What is so different about that?

      -- kryps

    3. Re:There but for the Grace of God go I by AKnightCowboy · · Score: 5, Insightful
      Each time a new local/remote root vulnerability is found the only way to be certain you haven't been cracked is to reinstall from scratch.

      Or just go back and run a filesystem scan against your known-good tripwire or AIDE database you keep on CD to see which files have been modified. Of course, you need to do it from single user mode after booting off a known-clean boot media like the install CD, but that's a helluva lot better than reinstalling everything. Sure, if you don't have a good tripwire database setup then you need to reinstall.

  2. Not surprising by NaCh0 · · Score: 5, Insightful

    These days with files, nis, nis+, ldap, and different encryption schemes, passwd is a complicated program.

    1. Re:Not surprising by larien · · Score: 4, Insightful

      Shouldn't need to be; most of that should be handed off to the PAM modules.

    2. Re:Not surprising by mst76 · · Score: 5, Informative
      > Shouldn't need to be; most of that should be handed off to the PAM modules.

      A quote from the changelogs of Slackware 9.1, just to offer a different perspective:
      openssh-3.7.1p2.
      This fixes security problems with PAM authentication. It also includes several code cleanups from Solar Designer. Slackware does not use PAM and is not vulnerable to any of the fixed problems. Please indulge me for this brief aside (as requests for PAM are on the rise):
      If you see a security problem reported which depends on PAM, you can be glad you run Slackware. I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you're missing out on the fun. (No, don't do that)
      OK, I'm done ranting here. :-)
  3. Risk assessment by achurch · · Score: 5, Interesting

    The risk is MEDIUM. A local unprivileged user may be able to gain unauthorized root privileges. [...] There are no reliable symptoms that would show the described issue has been exploited to gain unauthorized elevated privileges to a host.

    . . . and this is "medium"?

    1. Re:Risk assessment by REBloomfield · · Score: 4, Insightful

      yeah, it affects one box only, potentially. the same as viruses that trash your drive are classed medium, because you know that they are there. the bad ones are the ones that have screwed all your backups before you realise.

    2. Re:Risk assessment by gl4ss · · Score: 4, Interesting

      yeah well..

      if you would consider a remote exploit to be HIGH, that leaves a local exploit at medium, no?

      hmm.. what would be a low risk then.. maybe some game giving access to the game users privilidges..

      --
      world was created 5 seconds before this post as it is.
    3. Re:Risk assessment by achurch · · Score: 4, Interesting

      Yes, because prior authentication is required.

      Where is this stated? All I see is that /usr/bin/passwd has a local root vulnerability; to me, that says that if I can exploit a buffer overflow in any arbitrary program, even an unprivileged one, I can get root on the box.

    4. Re:Risk assessment by Florian+Weimer · · Score: 4, Insightful

      Where is this stated? All I see is that /usr/bin/passwd has a local root vulnerability; to me, that says that if I can exploit a buffer overflow in any arbitrary program, even an unprivileged one, I can get root on the box.

      You've conveniently removed what I wrote: This is true on any *NIX system, there are tons of vulnerabilities which allow attackers who can execute code under a non-root UID to obtain root access.

      It doesn't matter if you fix passwd(1). There are too many other issues, most of which still have to be discovered. You can't rely on local *NIX security, you have to use other means to stop attackers. For example, one widely-used approach is "one machine per service" or "one machine per trust domain".

    5. Re:Risk assessment by achurch · · Score: 4, Informative

      That's why I said "or your favorite buffer overflow exploit"; I just picked HTTP for an example because it's one of the better-known cases. My point is that "local" vulnerabilities become remote ones when paired with buffer overflows in programs accepting remote input.

      Besides, you can break out of a chroot jail.

    6. Re:Risk assessment by arr28 · · Score: 5, Insightful
      Please tell which vulnerability would screw all my properly made backups? By properly made backup I mean a backup that is made regulary to an external medium, like a tape or CDR, and is regulary verified to be readable.

      The issue here is that a virus may slowly corrupt your data over a long period of time. If, like a great many people, you recycle backup tapes - eventually all your backups will also contain the corrupt data.

      By the time you spot it, perhaps it's too late.
    7. Re:Risk assessment by LordKronos · · Score: 4, Insightful

      Please tell which vulnerability would screw all my properly made backups

      The type of vulnerability where, by the time you realize someone has exploited the vulnerability, all of your safe backups have been put back into rotation, and the only backups that exist anymore are the ones that were made after the system was compromised.

    8. Re:Risk assessment by Octorian · · Score: 5, Interesting

      Furthermore, the UltraSPARC has this nice feature you can enable where the stack space is non-executable memory. (a feature easily enabled in Solaris, and now OpenBSD as well) While it is still possible to exploit a buffer overflow with this feature, it us MUCH more difficult (google around, and you may find some writeups)

  4. Thanks Tim, here's some spam by utahjazz · · Score: 5, Funny

    Sun acknowledges, with thanks, Tim Wort (Tim.Wort@InklingResearch.com) for contacting
    us regarding this issue.

    I'm glad Sun thanked him by publishing his email address on a page now linked directly from the front of Slashdot.

  5. Re:Slowlaris is Dying! by prat393 · · Score: 5, Informative

    First, Solaris now runs on x86 architectures, so the idea of "expensive hardware" doesn't really add up - at least, not more than for any server. Second, as to insecure software; let he who is without sin cast the first stone - who among us has used a multiuser system without some sort of security flaws? As to "failure of security through obscurity," I really believe that Sun spends a good amount of time working on security fixes, and seems to actually care about these issues, unlike some companies I could mention.

  6. Re:Sigh... by Pond823 · · Score: 5, Funny

    It's ok, I already patched it for you ;)

  7. solaris bashing? by Anonymous Coward · · Score: 4, Insightful

    So it's a local privilege escalation, already fixed, with no published exploit in the wild? I have a feeling if this were linux then it wouldn't make the front page. (Which is a moot point as everyone knows you don't get security holes in linux. Just Windows and now Solaris.)

    And those two links make it look like Sol is plagued by root exploits. One's from a 1994 release of SunOS 4, the other's from nearly seven years ago.

    1. Re:solaris bashing? by null+geist · · Score: 4, Interesting


      > "Which is a moot point as everyone knows you don't get security holes in linux"

      really? http://www.linuxsecurity.com/advisories/index.html

      i develop cross-platform code for windows, linux and solaris so i am quite aware of many of these security issues. there is no such thing as a secure system; there are only secure admins

      -- ng

    2. Re:solaris bashing? by lewp · · Score: 5, Funny

      Sarcasm wasted on clueless reader. Film at eleven.

      --
      Game... blouses.
  8. Finally... by EmagGeek · · Score: 5, Funny

    Some news for nerds that actually matters... :)

  9. Re:What? How does this make sense? by Anonymous Coward · · Score: 5, Funny

    can we please think about these little jabs before tossing them around?

    "Won't somebody please think of the pedants?!"

  10. Further Proof by rixstep · · Score: 4, Funny

    'This is but further proof of the superiority of Microsoft Windows. Microsoft Windows has never had a problem with its passwd commands or files. I personally recommend Microsoft Windows for serious enterprise computing precisely for this reason.'
    - J Allchin

  11. Judge this based on what? by kd4evr · · Score: 5, Interesting

    Obviusly, security is the reason why the
    flaw isn't explanied in detail. Without
    more explanation, however, there is no
    way to tell how serious this really is.

    What's yellow and dangerous? A canary w/ root
    password.

    In my understanding of systems security,
    every security issue may be serious, but
    this one is definitely less than serious.

    A system that has no test:test accounts or
    guest logins, with all non-privileged users
    somehow known and/or affiliated with a systems
    administrator, chances of a major breach are
    slim.

    Incidental damage by a less skilled
    non-privileged user is another matter, though;
    likely and depending on the circumstances -
    reminds me of a poll once taken: would you trust
    your significant other with your root password?

    I hope this haiku style editing doesn't offend anyone.

  12. Big deal? by shin0r · · Score: 5, Insightful

    Let's not overreact here:

    a: vulnerability identified
    b: patches released to fix vulnerability

    all done *without* publishing a proof of concept / exploit for would-be skript0rs. There are no known exploits in the wild that abuse this vulnerability. Also bear in mind that user rights already need to be in place.

    --
    Super Awesome Broadband
  13. Re:so how does on go about exploiting this... expl by Goldfinger7400 · · Score: 4, Funny
    So how does one go about exploiting this... exploit?

    This is left as an excercise to the reader.

  14. Intelligent advertising system? by Anonymous Coward · · Score: 5, Funny

    When I first ran into this post, an ad of Sun appeared at the top of Slashdot's page which mentioned:
    "SUN MICROSYSTEMS TECHNOLOGY HELPS TAKE YOU PLACES YOU'VE NEVER BEEN BEFORE."

    Places I've never been before... Rootland?

  15. Nothing to see here by TheLinuxWarrior · · Score: 4, Insightful
    Ok, so we have a local root exploit.

    It's not as though Linux or the BSDs have never had one.

    At this point it becomes a matter of "how much do I trust the users on my systems?". Since none of my boxes are exposed to the public, and all my users are known/trusted employees, I can't say that this is really that big of a deal.

    Don't think I won't be patching it, all I'm saying is that the mere fact that the machine is powered on and connected to a network doesn't mean it's going to be 0wn3d.

    Save your energy/bashing for the next Windows worm that comes along that doesn't require having an account on the machine to break in.

  16. Re:Solution by ratsnapple+tea · · Score: 5, Funny

    I wasn't sure whether to believe you at first, so I looked it up and it turns out you weren't kidding! This is just too fucking funny.

    Why GNU su does not support the `wheel' group
    (This section is by Richard Stallman.)

    Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

    However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

    I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

    Typical RMS.

  17. Bzzzt! Wrong! by WIAKywbfatw · · Score: 4, Insightful

    Each time a new local/remote root vulnerability is found the only way to be certain you haven't been cracked is to reinstall from scratch.

    No, the only time that a new vulnerability is found, the only way to be certain that you won't be cracked in the future is to reinstall, or patch. Reinstalling doesn't retroactively guarantee that you haven't already been the victim of an exploit, which is what your post suggests.

    --

    "Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
  18. Security is a touchy issue for RMS by Stallmanite · · Score: 5, Insightful

    No passwords may seem strange to us, but try to try to keep in mind the context that created that attitude.

    The MIT AI lab was a tight knit community. It was very open, like a family for stallman. Passwords were just a way for the school to exercise control.

    http://www.oreilly.com/openbook/freedom/ch06.htm l
    http://catb.org/~esr/jargon/html/os-and-jedgar. htm l

  19. PAM by dmiller · · Score: 5, Insightful

    Yes, PAM creates more problems through its complexity, poor specification and an absolutely shocking API than it solves. I wouldn't be at all surprised if this bug was in the PAM library or a module.

    Don't believe me? Try writing a program that doesn't block during authentication. Try writing something cross-platform (there are at least three subtly different PAM implementations). Still not convinced? Have a look at the hoops that OpenSSH has jump through to work around this and other issues. Don't get me started on the busted config file that doesn't separate mechanism from policy or the stupid idea of dynamically loading modules in a security context....

    I'm surprised that the major distributions haven't moved on to something more sane. It's good that that Slackware, at least, has demonstrated some critical thinking and has not just mindlessly followed the flock.

    (disclaimer: I am an OpenSSH developer, very jaded for working with PAM for too long. OTOH, I'm not the only one)

    1. Re:PAM by R.Caley · · Score: 5, Insightful
      [...]the stupid idea of dynamically loading modules in a security context.

      Since I don't have any mod points today, ley me just add a hip-hooray to this.

      Being able to dynamically change the authentication behaviour with PAM was put forward as a reason why making /(s)bin/* dynamically linked in FreeBSD was a good thing. Seems to me that avoiding that is a great reason why such things should be statically linked.

      --
      _O_
      .|<       The named which can be named is not the true named
    2. Re:PAM by dmiller · · Score: 5, Interesting

      It is possible to build a useful and generic authentication system without dynamic loading.

      OpenBSD and BSD/OS have one (bsd_auth) that exec()s small helper programs which implement the actual auth methods. These helpers speak a little protocol to the library via stdio.

      The use of dynamic linking here is just lazyness on the part of people who would rather throw hidden complexity at problems rather than solving them through careful design.

    3. Re:PAM by R.Caley · · Score: 4, Interesting
      It is possible to build a useful and generic authentication system without dynamic loading.[...]

      Actually, I'm not convinced that an easily changable/extensible authentication system is a plus. Changing how authentication happens should be hard, most of the people who want to change how your aithentication works are the bad guys:-).

      Compared to the amount of thought and planning that should go into a decision to allow an extra kind of authentication, the effort of, say, rebuilding the system is small.

      Maybe I'm just old and paranoid...

      --
      _O_
      .|<       The named which can be named is not the true named
    4. Re:PAM by six809 · · Score: 4, Informative

      I wouldn't be at all surprised if this bug was in the PAM library or a module.

      Neither would I. From the patch details:

      Files included with this patch:

      /usr/lib/libpam.so.1
      /usr/lib/llib-lpas swdutil
      /usr/lib/llib-lpasswdutil.ln
      /usr/lib/pa sswdutil.so.1
      /usr/lib/security/pam_authtok_check .so.1
      /usr/lib/security/pam_authtok_get.so.1
      /us r/lib/security/pam_authtok_store.so.1
      /usr/lib/se curity/pam_dhkeys.so.1
      /usr/lib/security/pam_ldap .so.1
      /usr/lib/security/pam_passwd_auth.so.1
      /us r/lib/security/pam_unix_account.so.1
      /usr/lib/sec urity/pam_unix_auth.so.1
      /usr/lib/security/sparcv 9/pam_authtok_check.so.1
      /usr/lib/security/sparcv 9/pam_authtok_get.so.1
      /usr/lib/security/sparcv9/ pam_authtok_store.so.1
      /usr/lib/security/sparcv9/ pam_dhkeys.so.1
      /usr/lib/security/sparcv9/pam_lda p.so.1
      /usr/lib/security/sparcv9/pam_passwd_auth. so.1
      /usr/lib/security/sparcv9/pam_unix_account.s o.1
      /usr/lib/security/sparcv9/pam_unix_auth.so.1
      /usr/lib/sparcv9/libpam.so.1
      /usr/lib/sparcv9/ll ib-lpasswdutil.ln
      /usr/lib/sparcv9/passwdutil.so. 1
  20. User space part of Solaris gives Un*x a bad name by mi · · Score: 4, Insightful

    The kernel may be great and uber-stable, but the user-space utilities shipped with the OS are ancient and full of bugs long ago resolved in *BSD or Linux offerings.

    I am talking about awk, grep, diff (still no unified diffs!) and the like. The default shells -- sh and csh -- do not even allow for command line editing. make is outdated. vi borks if you extend your xterm too wide.

    Sure, you change the login shell to bash or tcsh, you can install the GNU utilities. Or BSD, for that matter (I ported FreeBSD's make(1) myself to use the bsd.*.mk files). But then, hey. you can even customize Windows to be almost like Un*x...

    The "out of the box" installation should be -- and can be -- much better...

    To bring this back on topic, it seems to me, the major thrust of the Solaris development is on kernel. The user space side -- including the passwd(1) -- is neglected.

    --
    In Soviet Washington the swamp drains you.
  21. So how do you manage your Sun patches? by Oestergaard · · Score: 4, Interesting

    Just curious.

    I used to download the patch clusters, but for single patches (or just few patches) that seems a little excessive.

    I'm trying out PatchPro now - you can get it from Sun for free. But it's some 100MB+ java monster process, requires WBEM, and god knows what. Not exactly light weight or minimal by any means.

    I was hoping for something roughly equivalent to "apt-get update; apt-get upgrade" - right now I'm at "smpatch update" which would be allright I guess if the WBEM services didn't take up half the memory in the box, all the CPU, and generally just took ages to run.

    Bigadmins (with enough time on your hands to read slashdot), what do you do?

  22. Workaround plus bad hyperlinks by ziegast · · Score: 5, Informative

    So there's no workaround ...

    How about "chmod ug-s /bin/passwd"? Someone running passwd wouldn't be able to escallate their uid/gid. To change passwords, run su(do) first. On systems wehre users arn't expected to change their passwords (web servers, etc.), this is usually a good preventative step for most setuid programs.

    And for the Love of Scott, if you're going to tell the world about a patch, please, oh please, make sure the hyperlinks work.

    Here's Sun's announcement, and if I click on the links to get patches,....

    Sparc
    Solaris 8 with patch 108993-32 or later
    Solaris 9 with patch 113476-11 or later

    .... the links give me:

    Sorry! We couldn't find your document.

    The file that you requested could not be found on this server.

    G'dammit!

    -ez

    Karma: Whore (you look at your score after posting)

  23. Nothing about the freebsd tcp/ip stack flaw? by chrysalis · · Score: 4, Insightful

    It's nice to have Slashdot posts about important security flaws.
    But why is there nothing about the highly more critical and remotely exploitable tcp/ip denial of service discovered in all versions of FreeBSD ?

    --
    {{.sig}}
  24. Too easy... by KillerHamster · · Score: 4, Funny

    You're worried you may have a script kitty?

  25. This will linger on for quite a while... by lythander · · Score: 4, Informative

    The patch for Solaris 8 is a giant PITA. Install in single user mode only, lots of patch incompatibilities, very sysadmin and uptime unfriendly. Many won't apply it because of the downtime it involves. At least not until there's an exploit. Then there will be hell to pay.