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

Not surprising

[NaCh0]

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

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

Risk assessment

[achurch]

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

Re:Risk assessment

[arr28]

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.

Re:Risk assessment

[Octorian]

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)

Thanks Tim, here's some spam

[utahjazz]

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.

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:There but for the Grace of God go I

[Avian visitor]

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.

Re:Sigh...

[Pond823]

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

Finally...

[EmagGeek]

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

Re:What? How does this make sense?

[Anonymous Coward]

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

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

Re:There but for the Grace of God go I

[kryps]

"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

Judge this based on what?

[kd4evr]

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.

Big deal?

[shin0r]

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.

Intelligent advertising system?

[Anonymous Coward]

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?

Re:Solution

[ratsnapple tea]

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.

Re:There but for the Grace of God go I

[AKnightCowboy]

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.

Re:solaris bashing?

[lewp]

Sarcasm wasted on clueless reader. Film at eleven.

Security is a touchy issue for RMS

[Stallmanite]

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

PAM

[dmiller]

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)

Re:PAM

[R.Caley]

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

Re:PAM

[dmiller]

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.

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)