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

Re:There but for the Grace of God go I

[Anonymous Coward]

I didn't say there was no patch, I said there was no workaround. Sometimes when there is a vulnerability, the way in which you run *your* system means you were not affected.

Also, I realise that when you *know* you've been infected, you always reinstall. This much is blindingly obvious. What I said was there were no symptoms! It's a local exploit with no symptoms. You don't *know*, and you can't *tell* whether it's been used. *EVERY* Solaris machine with multiple users ought to be reinstalled. I think this is a bigger-than-average problem!

As for what the f*ck I was talking about, I was trying to head off the usual plethora of "it won't happen to us" comments that something like this usually throws up. Linux advocates (at least on /.) can sometimes be ostrich-like in their outlook...

Clearer ?

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

[the_duke_of_hazzard]

Seems fair enough: high would be "can the bad guys get in?" and medium would be: "once in, can the bad guys do any damage?" If someone unauthorised/untrusted has user privileges, a lot of damage could still be done, and is worrying in itself.

Re:Risk assessment

[Anonymous Coward]

No, the medium rating is because the exploit is for local users only. It's not a remote exploit, and it takes a bit of work to run.

In most working environments, the local users have root access anyway through rebooting the machine into single user mode or through shoulder surfing their comrades, or in a Sun NFS environment by playing games with switching local user-ID on an unsecured box and taking over the admin's personal account by various means.

Mind you, I'm shocked, *shocked* to discover that a security critical, closed source tool was not written well or properly code reviewed by the small number of people who ever got to see the code. This is especially true when the same function has been implemented for more than 15 years in freeware (back in BSD UNIX), and has simply hundreds of exceedingly good freeware variants.

This sort of whackiness is part of why I won't use Solaris. They insist on using closed source and inferior versions of most system tools: du, ls, tar, compress, cp, NIS, NFS, and many other core utilities are of older and far more painful variants than the available freeware variants.

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:Risk assessment

[Anonymous Coward]

Most Solaris systems aren't shell systems- they're single or low function servers like Web servers, DNS servers, mail servers, etc. For those cases, chmod -s /bin/passwd, and let the admins who have access modify their passwords as root.

A poorly written cgi script can turn a local expoit on a single use machine to a remote root exploite very quickly.

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

Re:Big deal?

[Mr_Silver]

all done *without* publishing a proof of concept

If the patch exposes the source code required to fix it, then you're three-quarters of the way towards an exploit.

Re:Solution

[DashEvil]

So let me get this straight....

I buy a computer, I install Linux on it and give him local access to it.

How does this, in his eyes, make me the equivilent of some horrible dictator, and why does he feel like he has the devine right to exercise complete control over the machine?

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

Re:Ok , so hows it done?

[cyb97]

yes please post a step-by-step instruction on how to r00t your local solaris-box on the front page of slashdot.

There is a reason why most security-teams allow vendors to fix stuff before going full-disclosure...

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?

Re:Security is a touchy issue for RMS

[jdreed1024]

Passwords were just a way for the school to exercise control.

Is this "school" you speak of MIT? If so, it's worth pointing out that the root password for any public workstation at MIT is available to any user of the system. However, it's still not a carriage return, because that would be stupid. And users still have their own passwords, because in this day and age, having no password is dumb. Yet if they want root, all they have to is ask. (Well "ask" by means of typing a command - there's no approval process) So it is possible to have passwords and yet still make root available for anyone who asks. Individual passwords make sense because no matter how close knit a "family" you are, some things need to remain private. Would you show your porn collection to your spouse/partner? Would you your mom intimate love letters you wrote to your significant others? Would you show all your cousins the letter from your best friend telling you he's coming out of the closet? No, of course you wouldn't.