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

There but for the Grace of God go I

[Space cowboy]

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

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

[gl4ss]

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

Re:Risk assessment

[achurch]

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.

Re:Risk assessment

[achurch]

Agreed; the advisory is feather-light on details so I can't tell how easy it is to exploit. My main concern (as I've mentioned in other replies) is that many "local" exploits can become remote exploits as well via otherwise-harmless buffer overflows in other programs. If the bug actually requires you to use a terminal to exploit it, it's not so bad as if it could be triggered by a simple execve(...), in which case any daemon not chroot'd becomes a potential avenue of attack.

Re:Risk assessment

[anno1a]

At my university we run large solaris servers where about 12000 users have access. I'd say the risk here is a little more than medium, if we aren't even able to determine who the culprit is. Of course if the Solaris box was used as a local install only for one user the risk would be medium, but aren't Solaris primarilly used for servers (lots of users, lots of risk)?

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)

Re:Solution

[prat393]

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.

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.

Re:solaris bashing?

[null geist]

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

So how do you manage your Sun patches?

[Oestergaard]

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?

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.

Re:PAM

[R.Caley]

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

Patch links broken?

[doc_traig]

The Sun links to 108993-32 and 113476-11 (SPARC Sol. 8 and 9) seem to be 404ing... anyone have valid links to grab the patches over HTTP?