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

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

Comments

Re:Slowlaris is Dying!

[prat393]

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.

Re:Sigh...

[six809]

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

Solaris is secure

[thedaemontroll]

I've been using Solaris (and before that SunOS) for years on my company's servers and there's never once been a root exploit. As with any OS, you just have to keep it patched.

Re:Slowlaris is Dying!

[Loconut1389]

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.

Re:Not surprising

[mst76]

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

Re:solaris bashing?

[null geist]

actually, i also meant to give this link:

http://www.sunsolve.sun.com/pub-cgi/search.pl?mode =results&so=date&coll=fsalert&zone_32=category:sec urity

as i said, there is no such thing as a secure system. so, i really don't understand why news like this make it to the front page. to warn people? as an admin, you better follow these things and if you don't, you deserve to be vulnerable anyways

-- ng

Re:There but for the Grace of God go I

[Anonymous Coward]

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

That's why the security extensions put in place by the NSA's enhancements to Linux are so important. They make it so that even root has limited privileges - so, for example, root couldn't tamper with log files.

Having said that, remote logging would be better anyway.

Re:Risk assessment

[achurch]

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.

Re:Solution

[Florian Weimer]

This is, in fact, pretty similar to Richard Stallman's philosophy, and is elaborated on in the su info page, about why su doesn't support the wheel group.

Fortunately, with PAM support, you can implement a wheel group easily.

(And yes, I'm guilty of discriminating against many users: "www-data", "nobody", "mail"...)

Workaround plus bad hyperlinks

[ziegast]

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)

Re:PAM

[six809]

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

This will linger on for quite a while...

[lythander]

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.

Re:This will linger on for quite a while...

[dy2t]

I have used Live Upgrade to manage patches on Solaris systems. It lets you create a clone (or "alternate boot environment" in Sun's terminology) of your running system then apply the patches to the clone. The whole time the patching is taking place (and it can take a while) the "original" system is still running as usual (well, maybe a little slower due to the patching of the cloned system.)

When it is done, you just need to reboot and your system is patched. If something does not work, it is very easy to just reboot back into your original, pre-patched boot environment then figure out what went wrong (kind of like a save game feature!)

So, Live Upgrade is handy for maximizing uptime while not ignoring patches. Like you, I do not understand why so many Solaris patches want you to apply them in single user mode, then reboot afterwards, though.

Re:There but for the Grace of God go I

[Highlander]

I interpreted the initial comment to mean that it wasn't time for all the Linux users to point fingers at the Solaris users, I didn't see Windows in the equation at all.

H

Re:PAM

[Permission Denied]

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.

Re:Risk assessment

[forlornhope]

At my university, we run a solaris box as our file server. We only allow logins from admins and only via dsa ssh_keys to the system. We do this with all our production servers(web, mail, zope, database, etc. all running debian), but we also run many desktop systems and two shell servers running debian as well. We assume that these machines will be comprimised, corrupted, and/or otherwise broken. As such we manage them all via a system call FAI that we can reinstall the system at any time via a floppy and about 30 minutes of time.

Basically we keep all the systems that need to be up all the time safe from normal user login( normal users login via ldap) the same way we do with our file server, and those systems that can be comprimised we keep them so we can reinstall easily and quickly. This system is surprisingly flexible, secure, and easy to use. I dont see why more organizations dont use this type of setup. We assume we will be comprimised and are putting into place a system in which comprimises, hardware failures, and other mishaps dont matter.

P.S. We are currently moving all our machines to FAI including replacing the solaris file server running NFS with two debian file servers running OpenAFS. After that any of our machines can be comprimised and with our nightly back-ups we will be back up and running in as little as a few seconds(fail-over) to at most a few hours if we have to reinstall, patch, and restore.

Re:There but for the Grace of God go I

[gnu-generation-one]

HowTo: remote logging in Linux

Might be worth offering a web-application sometime, you could host lots of peoples' offsite logs, just like remote backup except without the bandwidth.

Other than that, looks like you'll need a spare PC.

Re:There but for the Grace of God go I

[Shanep]

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.

Amen brother. Last time I installed Solaris 9 (4/03 SPARC), I moved my DVD-ROM drive from my Thunderbird to my Sun Ultra 10, just so that I could install from the Solaris 9 DVD (quicker transfer rate, much less disk juggling and thus less requirement to hang around waiting for prompting).

It still took many hours to get Solaris installed to the (starting) point where I'd want to use it... then there were patches (well over 100) to download and apply...

Anyone want to suggest the best way to patch Solaris 9? I am currently using pprosvc and find it painful (I know it makes patching easier, but when there are 100+ patches, I don't want to do each by hand).

It's times like these that I really appreciate OpenBSD's install, which typically takes me about 3 minutes to install the base system, another 5 minutes to configure X and then maybe an hour to install and configure all the desktop productivity stuff I want.

Hell I can build release (all including X and ports) OpenBSD -stable quicker than it takes me to install my basic Solaris 9 (desktop, compilers, StarOffice).