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

[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: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

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

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

[ssbljk]

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.

hmmm I don't think it's real to expect reinstalling machines after every local (or remote) root vulnerability discovered... you will need bunch of admins just to keep on reinstalling systems, testing them, and, instead of going into production, reinstalling them again...

Re:There but for the Grace of God go I

[clarkcox3]

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!

And what he was saying is that this is no different than any root exploit in this respect, so it isn't a "bigger-than-average problem". Any time that there's a root exploit on any platform, Linux, Solaris, Windows, BSD, whatever, the cracker can always cover their tracks. So, by your logic, whenever an exploit is discovered in Linux, "*EVERY* [Linux] machine with multiple users ought to be reinstalled".

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

[The Spoonman]

"So, what are the chances of it happening on Linux ? Well, probably less (the many-eyes scenario), but certainly possible.

How quickly the mind of the Linux hacker forgets when the exploits happen. How about the mremap local root exploit which was in BOTH the 2.4 and 2.6 Linux kernels? In other words, despite the "many-eyes scenario", not a single person caught until it was used to attempt to fuck with the Debian CVS. How many MONTHS was it in there? How many more are out there, overlooked? Just 'cause they haven't been found yet doesn't mean they ain't there.

Really, it's time the Open Source community stopped spreading their own FUD and start dealing with the problem: Linux is no more secure than any other OS, including Windows. Complacency is going to lead to downfall.

I'll ask you the same question I ask every open sourcer who tells me about the "many-eyes": do you look at every line of code you run on your system? If the answer is no, then who does?

Re:There but for the Grace of God go I

[russellh]

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

My Ultra 10 with Solaris 8 is absolutely secure. I have every confidence it has not and will not be hacked. This is Sun we're talking about. They are the dot in dot com. The network is the computer. As a vote of confidence, I have placed my Ultra 10 in my closet, off.

Re:There but for the Grace of God go I

[Mr. Piddle]

It is still important for both Linux' and Solaris' sake that this is a local exploit. Multiuser systems are certainly at risk, but it is unlikely for this to spread around the globe causing billions of dollars of lost productivitiy like a Windows worm.

Even though UNIX' model is thirty years old and actually very simple in concept, it provides enough containment (and maturity) that global disasters are not terribly likely among UNIX systems. Also, with at least a dozen kernels out there, heterogeneity works to our advantage.

Re:There but for the Grace of God go I

[Too Much Noise]

And what he was saying is that this is no different than any root exploit in this respect, so it isn't a "bigger-than-average problem".

Actually, it kind of is. Remember that Solaris is considered by many the large, general-purpose multi-user Unix system(*). There aren't nearly as many multi-user Linux installs as there are Solaris instals. Government, military, education, you name it. Partially related to the all those certifications Sun has for it, partially to the (justified) mistrust in Windows for anything bigger than a medium-size multiuser server, partially due to the education system where the university ran solaris so future sysadmins learned that and then later used what they knew.

bottom-line: there are LOTS of Solaris machines out there and (too) many of them are large multiuser systems - meaning lots of untrusted users. As opposed to 'lots of Linux servers, not many of them with lots of untrusted users (yet). This will be a nightmare for many Solaris sysadmins.

(*) granted, given the Sparc's performance these days, that's one of the few left things one could still want to do with Solaris on big tin.

Re:There but for the Grace of God go I

[TobiasSodergren]

There's a lot of positive side effects with that tactic:

1) The computer will be secured no matter what OS you install
2) You'll get smaller electricity bills

As long as your closet is above earth level, the computer will also be reasonably safe from being infected by worms too!

Re:There but for the Grace of God go I

[BlackHorse]

Just bring in help from the Windows department. They are very experienced in the sort of repair you suggest. What would you like to format today?

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

Not surprising

[NaCh0]

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

Re:Not surprising

[larien]

Shouldn't need to be; most of that should be handed off to the PAM modules.

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

[REBloomfield]

yeah, it affects one box only, potentially. the same as viruses that trash your drive are classed medium, because you know that they are there. the bad ones are the ones that have screwed all your backups before you realise.

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

[Florian Weimer]

. . . and this is "medium"?

Yes, because prior authentication is required. Local security on *NIX is known to be rather weak, and only the clueless rely on it for critical applications.

Re:Risk assessment

[Tony-A]

. . . and this is "medium"?
Solaris isn't really the sort of system where you tend to have untrustworthy users.
A lot also depends on the difficulty of doing the exploit.

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

[Florian Weimer]

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.

You've conveniently removed what I wrote: This is true on any *NIX system, there are tons of vulnerabilities which allow attackers who can execute code under a non-root UID to obtain root access.

It doesn't matter if you fix passwd(1). There are too many other issues, most of which still have to be discovered. You can't rely on local *NIX security, you have to use other means to stop attackers. For example, one widely-used approach is "one machine per service" or "one machine per trust domain".

Re:Risk assessment

[Avian visitor]

the bad ones are the ones that have screwed all your backups before you realise.

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.

Backups that can be destroyed by a software flaw without an intervention of an operator aren't worth much.

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

[sql*kitten]

Where is this stated?

I can't think of a case in which one can run /bin/passwd without having already logged in. Perhaps you are thinking of /bin/login?

Re:Risk assessment

[Loconut1389]

True, and the desire to hack sun boxes decreases with the age of machines. Who wants to hack an ultra 10? Theyre not particularly fast. Unless you discover a nice Sun Fire V480 floating around on the network thats not tied down (ssh from specific hosts only, etc etc).. Most people just don't hack solaris. There's little gain. The types of script kiddies who do the hacking dont usually feel like porting whatever software they want to run over to solaris, or dont know how. Solaris is too much work for the unfamiliar. Theres much more advantage for a hacker to take over one of the abundant dual xeon machines running linux on the network.

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

[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: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

[LordKronos]

Please tell which vulnerability would screw all my properly made backups

The type of vulnerability where, by the time you realize someone has exploited the vulnerability, all of your safe backups have been put back into rotation, and the only backups that exist anymore are the ones that were made after the system was compromised.

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

[proberts]

> I guess that's why I like the idea of SELinux. Different domains > can prevent someone with even root access from messing with > your logs. Much less your libraries.

Sun's sold Trusted Solaris for years. If you want compartmented security, you have to pay for it in administrative overhead.

This is yet-another-local-exploit- it's perfectly valid to (a) swap out passwd if you don't need LDAP[1]/NIS, or (b) worry about a remote exploit that'll gain a local shell before patching this. This is "next maintenance window" in my book- but you can replace passwd without any downtime at all- or just remove the SUID bit if you don't have local accounts who need to do credential changes who don't have root access.

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.

Paul
[1] Guess where the problem appears to live?

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.

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:Thanks Tim, here's some spam

[nichomoff]

You've now thanked him by pointing that out to all! ;)

What? How does this make sense?

[anothy]

// This not the first nor the last time something like this has shown up.

what? doesn't that mean that the next root vulnerability would have had to already have shown up? or is the author precognitive? the link given as "last" certainly isn't...
can we please think about these little jabs before tossing them around?

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

Solution

[acceptera]

Solution: Stop using local user-accounts and distribute the rootpassword to the public. Simple!

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.

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

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?

Re:Sigh...

[Pond823]

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

solaris bashing?

[Anonymous Coward]

So it's a local privilege escalation, already fixed, with no published exploit in the wild? I have a feeling if this were linux then it wouldn't make the front page. (Which is a moot point as everyone knows you don't get security holes in linux. Just Windows and now Solaris.)

And those two links make it look like Sol is plagued by root exploits. One's from a 1994 release of SunOS 4, the other's from nearly seven years ago.

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: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:solaris bashing?

[lewp]

Sarcasm wasted on clueless reader. Film at eleven.

Finally...

[EmagGeek]

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

Re:Sun FUD on Security

[Anonymous Coward]

Yes, a single exploit makes his statements a lie.

Quit hoping you will get modded up for your unabashed Sun bashing.

Re:Sigh...

[six809]

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

Further Proof

[rixstep]

'This is but further proof of the superiority of Microsoft Windows. Microsoft Windows has never had a problem with its passwd commands or files. I personally recommend Microsoft Windows for serious enterprise computing precisely for this reason.'
- J Allchin

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.

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:Big deal?

[Anonymous Coward]

Umm. "Patches released" does not mean "Vulnerability fixed". Sun has, on numerous occasions, published a patch to fix a specific published exploit tool without actually fixing the underlying vulnerability. Look at the old "8lgm" references on the Net for examples.

The "8-legged-groove-machine" found that Sun only fixed vulnerabilities when exploits were published publicly, not when Sun was notified privately, and were repeatedly able to publish a new exploit tool within a week because Sun blocked the particular exploit tool and didn't actually fix the exploit.

Sun may have changed their approach, but since the source is closed, who can tell? If you want more robust security these days, go with the Sun Linux offerings, not Solaris.

Re:so how does on go about exploiting this... expl

[Goldfinger7400]

So how does one go about exploiting this... exploit?

This is left as an excercise to the reader.

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?

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.

Concerned

[Anonymous Coward]

While I'm glad its local only, I'm still worried. I have a Sun Blade 60 that I bought to learn Solaris on, and while I'm the only one using it, I don't know if I trust me cat. Should I be worried? I'll still patch as soon as possible...

fingers crossed, suspiciously stares at kitten....

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.

Nothing to see here

[TheLinuxWarrior]

Ok, so we have a local root exploit.

It's not as though Linux or the BSDs have never had one.

At this point it becomes a matter of "how much do I trust the users on my systems?". Since none of my boxes are exposed to the public, and all my users are known/trusted employees, I can't say that this is really that big of a deal.

Don't think I won't be patching it, all I'm saying is that the mere fact that the machine is powered on and connected to a network doesn't mean it's going to be 0wn3d.

Save your energy/bashing for the next Windows worm that comes along that doesn't require having an account on the machine to break in.

Bzzzt! Wrong!

[WIAKywbfatw]

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.

No, the only time that a new vulnerability is found, the only way to be certain that you won't be cracked in the future is to reinstall, or patch. Reinstalling doesn't retroactively guarantee that you haven't already been the victim of an exploit, which is what your post suggests.

How are you gentlemen?

[Anonymous Coward]

All your Solaris root password are belong to me.

phew

[Anonymous Coward]

I'm glad I never updated from Solaris 7, I'll be perfectly secure now.

I wuv you CDE.

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

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.

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.

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

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.

User space part of Solaris gives Un*x a bad name

[mi]

The kernel may be great and uber-stable, but the user-space utilities shipped with the OS are ancient and full of bugs long ago resolved in *BSD or Linux offerings.

I am talking about awk, grep, diff (still no unified diffs!) and the like. The default shells -- sh and csh -- do not even allow for command line editing. make is outdated. vi borks if you extend your xterm too wide.

Sure, you change the login shell to bash or tcsh, you can install the GNU utilities. Or BSD, for that matter (I ported FreeBSD's make(1) myself to use the bsd.*.mk files). But then, hey. you can even customize Windows to be almost like Un*x...

The "out of the box" installation should be -- and can be -- much better...

To bring this back on topic, it seems to me, the major thrust of the Solaris development is on kernel. The user space side -- including the passwd(1) -- is neglected.

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?

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)

Nothing about the freebsd tcp/ip stack flaw?

[chrysalis]

It's nice to have Slashdot posts about important security flaws.
But why is there nothing about the highly more critical and remotely exploitable tcp/ip denial of service discovered in all versions of FreeBSD ?

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

Too easy...

[KillerHamster]

You're worried you may have a script kitty?

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.

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?

Solaris 10

[kyoko21]

Good thing I just finished my download of Solaris 10. Why patch when you can just install a whole new OS? Oh wait, that's Microsoft's Security system. Looks like I'm going to get sued for reverse engineering... :-(

Re:Ok , so hows it done?

[Viol8]

What , you mean like all the exploits of windows and linux posted in full detail? Why is solaris exempt?

it's slashdotted

[Joe_NoOne]

Wow... sunsolve has been "slashdotted". Good thing they're the "dot in dot com" ;)