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."

9 of 283 comments (clear)

  1. 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.

  2. Re:Sigh... by six809 · · Score: 3, Informative

    Indeed. A quick round of chmod o-x /usr/bin/passwd to start with though.

  3. Re:Slowlaris is Dying! by Loconut1389 · · Score: 3, Informative

    I'm not sure what you mean by 'now'. Solaris has supported x86 for many a version, though laptop support has been iffy, especially w.r.t. pcmcia support. Not sure on solaris 9 and up. Solaris x86 doesn't have much of a place except in an otherwise all sun environment IMHO.. Might simplify some things. Depends on your situation I suppose.

  4. 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. :-)
  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. 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)

  7. 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
  8. 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.

  9. Re:PAM by Permission+Denied · · Score: 3, Informative
    OpenBSD and BSD/OS have one (bsd_auth) that exec()s small helper programs which implement the actual auth methods.

    Indeed, I just wrote a module for this. I needed one OpenBSD system to be able to authenticate users via LDAP. I did not want it to authenticate arbitrary LDAP users but only those who had local accounts.

    I had never worked with login.conf modules before. In fact, I didn't know they existed until yesterday. However, it took me exactly one hour to write a login_-ldap module that did exactly what I needed. I already knew my way around the OpenLDAP APIs, so this one hour was exactly the amount of time needed to figure out how this works. I had written a similar PAM module in the past and it took significantly longer to do that.

    Someone noted that PAM has the advantage that you can change policy on the fly without restart. This is not exactly true: applications load PAM modules at startup so if you make a change, you have to restart the application.

    OpenBSD login.conf works better than this as the authenticators are separate programs: I did not need to restart sshd or anything else. Changes were picked up as I edited /etc/login.conf and copied my program into /usr/libexec/auth. When developing a PAM module, you usually write a separate small program to test it, but I didn't need to do this with login.conf.

    There are other advantages as well: since the authenticators are separate programs, they can't screw up actual daemons if the authenticator has a bug. I also encountered some problems with PAM: occasionally one of the pointers in the PAM structure ended up NULL. This would screw up a particular daemon that I wrote since it would run fine for days but then crash when passed this NULL pointer. I don't know if the problem was in PAM itself or in the modules I was using. Once I figured out that this can happen (not documented anywhere, likely a bug), I was able to consider that NULL pointer as a failed authentication. This wouldn't have happened with login.conf: NULL pointer problems are limited to the authenticator and will not screw with the daemon. Basically, daemons use a safer communicaion system with the authentication subsystem.

    So I can say that OpenBSD login.conf is more flexible, safer and easier to administer than PAM. There are, however a couple of disadvantages that would turn off some people:

    1. You have to edit a termcap-formatted file. This was not an issue for me, but if you don't, for instance, know what ":tc=" means, you will very easily get confused. Careful reading of man pages solves this. Termcap-formatted files are really the "BSD" way of doing things, so I don't mind this as it's rather consistent.
    2. The system is more flexible, but that's partly because it's easier to write custom authenticators. You can't "stack" modules like in PAM, so I needed to write code to enforce the policy mechanism I needed (users must have local accounts before authenticating via LDAP). With PAM, you would just edit a config file, not write a C program. I don't believe this is too big of a disadvantage as lots of very valid policies are difficult to express in PAM modules. For instance, what if instead of local accounts I required users on this machine to have a particular LDAP attribute? Is there a PAM module that checks for attributes rather than binding? I don't think so, so you'd end up writing one. With both systems, you end up writing a module when you have a policy that can't be expressed with current modules, but that's much easier with login.conf.