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

[Anonymous Coward]

>>This isn't a time to be smug about not running Solaris...

course it is, when Windows exploits get published it's ok to be smug. Why not with Solaris??

Re:There but for the Grace of God go I

[Felinoid]

True. The advantage of using an open source OS is that your first best option is to fix it.
With Solarus your first best option involves liccensing the source.

I doupt many eyes would prevent this sort of bug. It's easy enough to make and even easier to miss.

So I'd say the chances of this happening to Linux is dead even with the chances of this happening to Solarus.

I'll be smug when the issue is cost. When it comes to security I bow to the master.

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

[CaptainCheese]

This isn't a time to be smug about not running Solaris...

You're right, it's time to feel smug about running windows. There are no surprising vulnerablities there...

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

[Anonymous Coward]

how did you write what was essentially a "ditto" post and get modded up to 5?

i am intrigued by your ideas and wish to subscribe to your newsletter.

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]

A local user with root privilenges can always prevent a reinstall from scratch.
Therefore a reinstall from scratch is not safe.
The only thing you can do is to:

• reinstall new flash BIOS and harddisks
• or burn your computer

Re:There but for the Grace of God go I

[hatrisc]

however, who's to say your backups are safe? vulnerability's weren't introduced in some backup.

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

[Perky_Goth]

Except for remote logging... which is security 101.

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

[Anonymous Coward]

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

That's exactly what he's saying. Read first, post later.

Re:There but for the Grace of God go I

[Anonymous Coward]

Patch and change your passwords?

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

[Short Circuit]

The insinuation is that it's not good to be smug about running Windows. But mentioning that directly gets you modded as a troll.

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

[Krunch]

Unless log messages are sent to another computer. I think syslogd can be configured to do that.

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

[jrockway]

Going up to the parent's parent's parent's parent, we see that this post concludes a string of five(!) consecutive posts containing an asterisk. Just thought that was interesting. :)

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

[Anonymous Coward]

well.. encryption proved itself not to be so efficient and secure itself (i.e. PGP)

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

[Anonymous Coward]

By that logic, I miss out on 100% of the security problems each year by running no OS at all. Isn't it grand?

Re:Not surprising

[Darren.Moffat]

The problem was in the PAM module NOT in the passwd(1) command which is acutally quite a simple command because of PAM.

Sigh...

[Tet]

I see lots of patching in my immediate future...

Re:Sigh...

[Pond823]

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

Re:Sigh...

[six809]

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

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

[Anonymous Coward]

yes, it's spelled m-e-d-i-u-m but pronounced "LOCAL"

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]

if you would consider a remote exploit to be HIGH, that leaves a local exploit at medium, no?

I dunno, personally I'd consider both of them high--many local exploits can be exploited remotely as well via buffer overflows and the like. I'd put non-root privilege elevation at medium, and things like denial of service that don't actually damage the system at low to medium, but it all depends on the particular circumstances.

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

[achurch]

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.

I'm sorry, I misinterpreted your earlier post. I'll agree that the "root" concept has many problems, but nonetheless root privilege does allow an attacker to do anything (modulo securelevel--does Solaris have that?) to the system. Also keep in mind that for many people, it's not worth the expense to use a stronger security system, and for such people this is (and other root-elevation issues are also) high-risk.

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

[Anonymous Coward]

So, medium (local root) + medium (remote non-root) = high (remote root).

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

[achurch]

I can't think of a case in which one can run /bin/passwd without having already logged in. GET /...shellcode.../bin/passwd HTTP/1.0

or your favorite buffer overflow exploit.

Re:Risk assessment

[batura]

Yeah, and that point being, is you actually have to have a user account or access to one. You can't get in to the system using this exploit, just something to do while you're already in.

Re:Risk assessment

[LizardKing]

GET /...shellcode.../bin/passwd HTTP/1.0 or your favorite buffer overflow exploit.

Any valid reason why you wouldn't be running the httpd daemon in a chroot jail?

Chris

Re:Risk assessment

[sql*kitten]

GET /...shellcode.../bin/passwd HTTP/1.0

Yeah, good point. 'Course if you can do that on a box, it's got more fundamental problems to worry about...

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

[Tony-A]

Theres much more advantage for a hacker to take over one of the abundant dual xeon machines running linux on the network.

True. You have to wonder why it's Microsoft Windows that seems to catch most all the malware. I would imagine that Linux would be a much more attractive target.

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

[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

[Sogol]

What about for changing your password?

Re:Risk assessment

[Dogtanian]

If, like a great many people, you recycle backup tapes - eventually all your backups will also contain the corrupt data.

Perhaps a good reason to use CD-R (not CD-RW) then?

Re:Risk assessment

[Sogol]

Did you read the article? The danger is that a local account could be elevated to root.

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]

Well, it's a medium-sized risk, but you can always super-size it by porting IE6 to Solaris.

Re:Risk assessment

[sporty]

No, just not stoned enough. /rimshot

Re:Risk assessment

[azaris]

Solaris isn't really the sort of system where you tend to have untrustworthy users.

Really? How about universities? Thousands of people with valid log-ins, generally poor information security, too many computers, not enough IT staff.

Re:Risk assessment

[Chris Mattern]

> but aren't Solaris primarilly used for servers (lots of users, lots of risk)?

Yes, and no. Servers generally *don't* have lots of users with shell account logins; your university user systems are an exception. In our own university data center, we have many large database/web/other servers that provide access to administrative information. You can count the number of people who have access to a shell prompt on these systems on your fingers.

Chris Mattern

Re:Risk assessment

[Anonymous Coward]

> Besides, you can break out of a chroot jail

Besides, there are better things then chroot, FreeBSD's jail is a lot more then chroot, and uml will also provide you with something better then chroot..

Re:Risk assessment

[Short Circuit]

I dunno, personally I'd consider both of them high--many local exploits can be exploited remotely as well via buffer overflows and the like.

Not only that, but as root, you can be anyone on the system. And you have access to everyone's private keys that they have on the system.

Do any of the users have key-based authentication to get into other boxes on your system? Guess what: You better consider those boxes compromised as well.

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.

Re:Risk assessment

[Ctrl-Z]

You mean a SetUID game game?
Gasp!

Re:Risk assessment

[Anonymous Coward]

I don't have fingers, you insentive clod!

So, that being the case, how do you admin the system with no shell accounts?

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

[Fishstick]

>The danger is that a local account could be elevated to root.

Right. But his point is you have to have that local account first.

Being able to log into the machine as joe-regular-user and then get root via the passwd command is bad -- but not as bad as a remote vulnerability that lets you get onto the machine in the first place (without having a legit local user account).

Re:Risk assessment

[addaon]

Perhaps, but 100GB CD's just make too good sombreros to waste on data backup.

Re:Risk assessment

[Dogtanian]

Perhaps, but 100GB CD's just make too good sombreros to waste on data backup

Uh?!.... 100GB CDs? I'd like to see that :-)

Actually, I realised literally seconds after I'd posted it what a lousy idea suggesting CD-Rs for backup was- 100 CDs per 80GB drive. If you couldn't afford anything better, writable DVD drives and media are cheap enough now and (I guess) just about usable for incremental background backups.

CDs though? Ugh.

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

[Mr Z]

...neither one of which is relevant or useful under SOLARIS.

Re:Risk assessment

[Anonymous Coward]

Perhaps a good reason to use CD-R (not CD-RW) then?

How do i fit 200 GB onto a cd-r? Either 286 cd-r's, 43 dvd-r's, or 1 LTO. But wait, i actually have a few TB's of data. Do cd-r's still sound good?

If long term data damage is a concern, keep one full backup every X amount of time for as long as you might ever need the data.

Re:Risk assessment

[Anonymous Coward]

Untrustworthy users? Because Solaris users are "good people"? Perhaps I misread your post, but imagine vuln solaris boxes containing sensitive data at the NSA or Boeing or the JPL etc.

General rule of thumb...none of your users are trustworthy.

Wariac

Re:Risk assessment

[Anonymous Coward]

the local users have root access anyway through rebooting the machine into single user mode

Do you understand what 'local' means? If i'm in Zimbabwe and can get a shell on a machine in Taiwan then i'm a local user for that machine.

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

It is also because you don't use Solaris that you don't understand why they do that. Legacy is a big issue when you're dealing with the real-world, long lifespan apps that Solaris servers run.

If you're going to complain about a whacky way that Solaris packages apps, complain about the revs they do to preexisting OSS they include, like OpenSSH. At least they do apache fairly well.

Re:Risk assessment

[Jim_Maryland]

The hacking direction really depends on your end goal really. If your goal is to disrupt a large number os systems, then your going to go to the desktop level and that's going to be your MS platforms. If your looking to steal corporate information (source code, customer records, etc...), your probably going to look for server type systems, and that branches your hacking effort into the UNIX world. You'll hack to where your end goals take you.

As to Who wants to hack an ultra 10? question, you'd probably be surprised by the number of these systems hosting critical applications. While the systems are definitely "old" by todays standards, they could be an entry point into a newer Sun systems. Figure that many companies are stretching their IT budgets and developer and maintenance IT staff will often sit at older equipment as their entry point into the "new" systems where the critical applications/data repositories are deployed. Just think of how many systems possibly have the .rhost files for user accounts.

Re:Risk assessment

[diablobynight]

Well, anything that might also look bad to the linux community, because much of linux, and solaris security tend to share the same form and function, although the code is much different. But if you said, Solaris, had a High Security risk, with something as serious as root priveledges, it may very well start to destroy the security supremousy that the slashdotters often claim, Solaris, Unix, Linux, OSX all have over Windows. And this is Slashdot, we stand by linux even if the ships sinking, because to fix the ship is to say it was broke in the first place.

Re:Risk assessment

[Tony-A]

General rule of thumb...none of your users are trustworthy.

Actually, all of my users are trustworthy.
(I trust my users far more than I do Microsoft;)
And if they aren't, the computers are the least of my worries.

Re:Risk assessment

[Anonymous Coward]

If you're reusing your backup media, that defeats the whole purpose of backing up your data - a reliable, unmodified copy of the work as it was when you left it.

The last company I did work for burned three copies of each backup CDR (not RW), two to remain at the company office in different locations, and one to remain at an offsite location.

I really hope you're overestimating by saying "a great many people" when you refer to how many people reuse their backup media. Doing that is just asking for loss of your backed up data. Just don't do it!

Re:Risk assessment

[Loconut1389]

Quite true. Plus theres the hackers that just like to cause trouble, though I think most of those fall under the 'dont understand solaris' catagory.

Re:Risk assessment

[Anonymous Coward]

The Athlon64 has the same feature. Indeed, it was mentioned on Slashdot some weeks ago. The IA32e doesn't honor the bit (yet).

Re:Risk assessment

[Shanep]

Actually, I realised literally seconds after I'd posted it what a lousy idea suggesting CD-Rs for backup was- 100 CDs per 80GB drive.

Assuming the 80GB drived was filled with data that was expected to be backed up.

I worked for a stock exchange which used CDR for certain backup tasks. They had rows and rows (like a library) of CDR's, not including the latest stuff which was shipped off site each night.

For many people and businesses, CDR storage is enough. The stock exchange at that time, also relied heaviliy on RS-232 and other low bandwidth lines to link to customers, simply because it met the requirements. Which is the point.

Re:Risk assessment

[proberts]

Yes, but a single-use machine doesn't need passwd to be setuid!
Single use machines rarely need anything other than /bin/login to be setuid. So, removing the setuid bit gains you all the security with none of the headaches- for the entire suite of stuff that's setuid by default. Viola! No more local exploit (and it's still a local exploit- you still have to gain access to get up to root.)

Paul

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:What? How does this make sense?

[addaon]

For they cannot think for themselves.

It's NEVER the last exploit.

Thank God..

[tarunthegreat]

I upgraded to XP. You people and your insecure operating systems. Next thing you know, you'll be able to bypass passwords by hitting the ESC key.

WE ARE THE INDIANS. YOUR TECHNOLOGICAL DISTINCTIVENESS SHALL BE OUTSOURCED. RESISTANCE IS FUTILE

Re:Thank God..

[Anonymous Coward]

Pst. You can't do that in NT based operating systems. You're thinking of the consumer grade Windows 9x.

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

[Anonymous Coward]

i sure as hell would make sure not to hire you to maintain my systems :-P

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

[caluml]

Who was the guy, way back when, that refused to have a password on his computer, saying that he shouldn't need one? Someone kindly telnetted in, deleted his emails, and then he changed his mind.

My 1000th post. What do I get?

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?

[Anonymous Coward]

Woosh. That was the sound of... You know the drill.

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.

Re:solaris bashing?

[DashEvil]

It would have made the front page.
I have no doubt about that. Nobody tries to hide Linux vulnerbilities. Microsoft ones are just funny because MS is know to be insecure, and there are ACTUALLY people out there who deny (Against all the proof) that Windows is insecure.
The vast majority of people posting here don't even seem to be insulting Solaris. I think you just want to discredit people here with bullshit.

Re:solaris bashing?

[elmegil]

It would have made the front page.

Yeah, right. Many people here would be aware of it, and it certainly wouldn't be hidden by the linux community, but the slashdot editors sure wouldn't consider it front page worthy. I personally have pointed out previously that Linux is no magic panacea, only to get modbombed to -1. Hm. That could easily be editorial behavior too, no telling.

The charge about Solaris bashing isn't against the community at large here either. Nobody's trying to discredit the "people" here, just commenting on the submitter and the editor who passed it on.

Finally...

[EmagGeek]

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

Re:Finally...

[musikit]

although i agree with you in one sense. give the relatively low number of *nix exploits found compared to windows exploits found if this was all slashdot reported it would be "news for nerds stuff that mattered" it would be "bug for windows stuff for hackers"

so how does on go about exploiting this... exploit

[Anonymous Coward]

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

- the midnight bomber which bombs at midnight

Re:Sun FUD on Security

[EmagGeek]

"..dramatically less expensive in purchase price..."

*puzzled look*

So I guess they *are* on SCO's side, since to even state that Linux HAS a purchase price is to imply that you're talking about a certain $699 protection racket...

Ok , so hows it done?

[Viol8]

"unprivileged user may be able to gain unauthorized root privileges "

Great. So how do they go about doing it? A bit more info would be useful such as what type of activity to watch for etc....

Re:Ok , so hows it done?

[Anonymous Coward]

it's called an exploit

and it's not "traceable", so you're best off patching it ASAP and praying that nothing bad happened

worse comes to worst.. fdisk/format/reinstall :-P

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

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?

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.

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

Re:Further Proof

[Fallen_Knight]

Microsoft Windows has a passwords?? i Thaugh that was broken as i always log on as administrator with no password...

Re:Further Proof

[Fishstick]

hmmm... whenever I forget my password I just hit [esc] and it lets me right in!!!

Re:Further Proof

[Anonymous Coward]

That's because you're running consumer grade Windows 9x. NT/2K/XP never allowed this. Even if you're trying to be funny, you shouldn't spread FUD, either toward Linux or toward Windows.

Re:Further Proof

[Fishstick]

No shit, sherlock: relax -- geez

just having a little fun. if anyone is so dumb as to take this for anything other than what it is... well... they're just DUMB!!!

Re:Further Proof

[Anonymous Coward]

Shut the fuck up. A little fun towards Windows is rewarded with moderation points and a few chuckles from Linzealots -- a little fun towards Linux is shunned and oppressed with negative moderation points and a lesser form of censorship (messages are still there, just more concealed from the public eye) and a pack of Linux-loving forum samurai who leap in to tell you eight million FUD-ish reasons why they are right to criticize like raving lunatics.

Honestly.

Re:Further Proof

[Anonymous Coward]

I think you seriously need to grow up and get some perspective, ass-bag.

Shut the fuck up

Indeed? Well, all I can say to that is...

nyaa, nyaa! Make me!

Fuck-tard

Re:Further Proof

[Fallen_Knight]

i didn't get any mod points for that...

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:Judge this based on what?

[Anonymous Coward]

What's yellow and dangerous?
SUN

Re:Judge this based on what?

[Anonymous Coward]

would you trust
your significant other with your root password?

Heh, which assumes that my other half would be clueless, however, she was running her own Linux boxes before we even met ;P Yeah, she has my root password as well, its just practical, and what I do at home that is of any importance is backed up pretty well ;)

Re:Judge this based on what?

[Anonymous Coward]

Ahhhh.... To be young and foolish in love. :-)

I don't trust my girlfriend with my password, why would I trust my wife?

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

[autocracy]

Yeah, but if you're the type that is mostly likely to use that, 3/4 is where you'll be stuck at.

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?

Re:Intelligent advertising system?

[Anonymous Coward]

Rootland?

No. A girl's panties.

wrong

[Anonymous Coward]

even if the exploit is not wild (yet), there is still that possibility that someone (or some people) do have this exploit... and for all we know, they may be floating around to a very limited amount of people (i know of at least one "place" where i'm sure it's being circulated right now as i write this)

secondly, patches aren't the answer... how many times have you applied BIND patches

need i say more?

lastly, "user rights already need to be in place".. well most admins that setup accounts do allow the user to use the passwd command.. so.. yeah

cheers

Re:wrong

[Anonymous Coward]

>even if the exploit is not wild (yet), there is
>still that possibility that someone (or some
>people) do have this exploit... and for all we
>know, they may be floating around to a very
>limited amount of people (i know of at least
>one "place" where i'm sure it's being
>circulated right now as i write this)

hur, i doubt that it's circulating on #ereet_teen_haxors. Of course there's a possibility, at any time, of exploits being circulated, for any app/binary/whatever.

>secondly, patches aren't the answer... how many times have you applied BIND patches

what? what is the answer then? Correct me if I'm wrong, but don't you patch broken software?

>need i say more?

please don't, i'll wet myself laughing.

>lastly, "user rights already need to be in place".. well most admins that setup accounts do allow the user to use the passwd command.. so.. yeah

We aren't talking about the shells you let your IRC buddies use from the machine in your basement here, fool.

PS: I'll have fries with that.

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:Solaris is secure

[Anonymous Coward]

give me an IP of one of your systems and i'll be more than glad to test it out for you :-)

Re:Solaris is secure

[OwlWhacker]

"As with any OS, you just have to keep it patched."

Unless you're using Windows, then you're caught between a rock and a hard place:

Do you risk not patching, or do you patch and risk your machine being devastated by yet another malicious Microsoft patch?

Actually, as Microsoft is automating it's patching process then either way your machine gets screwed. Trustworthy Computing at its finest.

Re:Solaris is secure

[ogre57]

'Never once been' is ambiguously phrased, believe you mean your systems have never been cracked. Congrats. Ours either. You are correct, keep up with patches, monitor (eg aide), so far zero problems. Wish everyone did. Got loaned to team in another wing to help them recover when they were cracked via snmp and again when they didn't bother to patch a new box for sadmind. Some people refuse to learn.

Re:Solaris is secure

[Anonymous Coward]

Give me a break...there are 0-dayz that have Nasa's systems 0wn3d silly. Just because you havent read of it, doesnt mean it isnt there. Someone in my company found an exploit in 2.6, contacted the company to alert them to the fact and a year later when 7 came up, lo and behold it was still there.

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

[Mr. Piddle]

Sun Blade 60

If you were to say this in an interview, the interviewer would silently cross your name out while nodding politely while you talk.

Also, you really need to be careful of that cat! Cats are masters at denial-of-service attacks. I'll see a little paw reach out and hit that power key on the keyboard, and, while he makes it look like an accident, his eyes reveal the truth. I've also heard the other cats talking...they're out to get us!

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.

Re:Nothing to see here

[thedaemontroll]

Exactly. The reason why it seems like a big deal to have a local root exploit on Linux/BSD/Solaris is because they're usually so reliable. Compare that to flaws in DCOM in Windows for example. The Windows flaws are much more serious.

Re:Nothing to see here

[Anonymous Coward]

hear here! it's not really much of a big deal at all, but that won't stop the zealots!

Re:Rule of thumb..

[Hektor_Troy]

Call it "Gaywins Law" instead.

No, wait ... that would call for stuff like "Gay Windows" jokes. Of course that would make it recursive. Or something like that. Maybe.

Of course this would make the trolls start an internal flamefest against eachother as to wether or not Gaywins Law is applicable to itself, so we wouldn't be bothered by them for a while.

Neat!

now it's my turn

[Anonymous Coward]

>hur, i doubt that it's circulating on #ereet_teen_haxors. Of course there's a possibility, at any time, of exploits being circulated, for any app/binary/whatever.

hur, maybe i wasn't referring to irc, hmm :-\

>what? what is the answer then? Correct me if I'm wrong, but don't you patch broken software?

well let's see, patches aren't always the answer my friend.. how about growing some balls and actually configuring (exclude passwd for this one moment) software and changing the code yourself rather than relying on patches

>please don't, i'll wet myself laughing.

you're right, how can i argue (and waste my time) arguing with someone so stupid and clueless like you

>We aren't talking about the shells you let your IRC buddies use from the machine in your basement here, fool.

i'm not even going to comment on that

PS: Get a clue.. oh and not everyone who posts counter-arguments are "irc kiddies"

Re:now it's my turn

[Anonymous Coward]

bwahahahahahaa

>well let's see, patches aren't always the answer my friend.. how about growing some balls and actually configuring (exclude passwd for this one moment) software and changing the code yourself rather than relying on patches

bwahahhaahahahaaa!

I'll have a large Coke too.

Re:now it's my turn

[Anonymous Coward]

wow, i truly must say, i have never met anyone as stupid and as shallow-minded as you

please do us all a favor and get a clue about computer security.. then post

Re:now it's my turn

[Anonymous Coward]

and a supersized mcflurry please.

Root vulnerability in passwd(5)

[Anonymous Coward]

I heard if you throw the password file at the filesystem hard enough, the root password falls out!

Re:Root vulnerability in passwd(5)

[Anonymous Coward]

You can't throw files, don't you know *anything*?

Re:Root vulnerability in passwd(5)

[DashEvil]

ln -sf /usr/bin/mv /usr/bin/throw
throw stfu /your/face

:)

industry best practices...

[Anonymous Coward]

dictate NOBODY that you don't trust should ever have any shell account on any server that you give a damn about.

If I have a client that wants shell access on any of our systems, he needs to have his own server on a separate segment that he can screw up any way he likes.

Seal off all ports not used; put everything in "safe mode" and if lamer programmers can't work around it, it's their problem. This negates about 99% of all these exploits. It goes without saying not running any Microsoft products means I get a full 8+ hours of sleep (during the day of course).

404

[inf0c0m]

anyone else getting a 404 on sun's website when trying to get the patch info? anyone have a link to the right page?

Re:404

[Anonymous Coward]

Not getting 404, but the patch page is responding like grandma's molasses in January!

Re:404

[Anonymous Coward]

instead just
ftp sunsolve.sun.com
cd patches

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.

Re:Bzzzt! Wrong!

[Politburo]

The wording is slightly incorrect, but his point is correct. After an exploit is released, the only way to be certain that you aren't currently cracked is to reinstall. It guarantees that if you were the victim of an exploit, you aren't anymore.

Re:Bzzzt! Wrong!

[Anonymous Coward]

+5 insightful.. -1 redundant.. mods are really using their reading comprehension skills today

Slashdot automatons

[Anonymous Coward]

...
if (bIsLinuxZealot)
{
if (bMicrosoftExploit)
BitchAboutMicrosoftIrresponsibility();
else
NothingToSeeHere();
}

All OSs have vulnerabilities. Get over it.

How are you gentlemen?

[Anonymous Coward]

All your Solaris root password are belong to me.

Re:How are you gentlemen?

[Anonymous Coward]

Solaris, Solaris, Solaris, Solaris,
Solaris, Solaris, Solaris, Solaris,
Solaris, Solaris, Solaris, Solaris,

Exploit, exploit!

Root! Got root! Ooo-aaarrgh! They got root!

www.badgerbadgerbadger.com

Re:How are you gentlemen?

[Anonymous Coward]

Eat hot Zig fighter zaps, gentleman.

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

[Anonymous Coward]

This is a late post to your comment, but logging in to ITS (The MIT AI Lab OS from back in the day) was optional. You didn't need to do it, the only reason to login was so your personal settings were used.

Dig?

Re:Security is a touchy issue for RMS

[Stallmanite]

There were no passwords on ITS because of stallman's philosophy

from stallman's biography:

"The hackers who wrote the Incompatible Timesharing System decided that file protection was usually used by a self-styled system manager to get power over everyone else," Stallman would later explain. "They didn't want anyone to be able to get power over them that way, so they didn't implement that kind of a feature. The result was, that whenever something in the system was broken, you could always fix it."

Through such vigilance, hackers managed to keep the AI Lab's machines security-free. Over at the nearby MIT Laboratory for Computer Sciences, however, security-minded faculty members won the day. The LCS installed its first password-based system in 1977. Once again, Stallman took it upon himself to correct what he saw as ethical laxity. Gaining access to the software code that controlled the password system, Stallman implanted a software command that sent out a message to any LCS user who attempted to choose a unique password. If a user entered "starfish," for example, the message came back something like:

I see you chose the password "starfish." I suggest that you switch to the password "carriage return." It's much easier to type, and also it stands up to the principle that there should be no passwords.

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.

Re:Security is a touchy issue for RMS

[duffbeer703]

That's a big problem with RMS... he has devoting his life to replicate a particular time at a particular place with a unique group of people.

It's not gonna happen... and it is kinda sad.

Re:Security is a touchy issue for RMS

[addaon]

There's a difference between showing and not hiding. In all those cases (well, except the first; I show my gf my porn collection all the time) I might not show it, but I'd not hide it. Maybe I just am less ashamed of my life than you, I don't know.

Re:Security is a touchy issue for RMS

[Mr. Piddle]

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.

There is no privacy against a snooping root user. If a spouse/partner has the availability of root access on the porn file server, then the spouse/partner has full access to the porn collection, too. Unless some sudo/RBAC scheme is devised, root == God in UNIX-land.

Re:Security is a touchy issue for RMS

[soulsteal]

Would you your mom intimate love letters you wrote to your significant others?

My mom is my significant other, you insensitive clod!

Re:Security is a touchy issue for RMS

[aardvarko]

Is this "school" you speak of MIT?

No, not at all. That part about the "MIT AI lab" was just thrown in to add a little spice, a little New-Radicals-Courtney-Love-Marilyn-Manson intrigue. You did the right thing by totally ignoring it.

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

[sik0fewl]

That means nothing. 5 out of those 23 files don't even have the word 'pam' in them.

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

[Electrum]

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.

That sounds very similar to the checkpassword program and interface. Is that a coincidence?

Re:OPEN SOURCE = GARBAGE. PROOF!!

[Duty]

Solaris isn't open source, genius.

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.

Re:OPEN SOURCE = GARBAGE. PROOF!!

[Anonymous Coward]

MY COMMENT IS IN RUINS! THE PAGE WAS Fixed!
But it said "Open source is garbage."!!

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:So how do you manage your Sun patches?

[dy2t]

Solaris SRS Net Connect is a relatively recent system management offering. I saw a demo of it recently and, among other things, it supposedly automatically alerts you of new patches of your system(s). It probably just uses PatchPro to do that, though. It is a free product for now (with extra services that you can buy) and you need to have all your system info stored on a centralized system managed by Sun, but I am sure they promise not to spy on you.

I think that PatchPro requires you to have a service contract/ESID number with Sun (not a problem for most companies, I guess.) I believe also that even access to the Solaris bug database (just to read descriptions--handy if you are trying to figure out if a problem is due to you or Sun) can only be done if you are a paying Solaris customer.

Re:So how do you manage your Sun patches?

[thogard]

Sun's ability to patch OS problens with such a beast is why I run other things now.

A good solaris install is tiny and compact but sun has no clue about that these days and it will kill them as a company.

How many others do a command like find +atime | sed ... | rm to clean up unwated stuff in the base distro? 95% of standard solaris distor will never be used so why is it ever installed?

Re:So how do you manage your Sun patches?

[Anonymous Coward]

We have an Engineering team that vests patch clusters quarterly and provides ad-hoc scripts for installation.

For urgent security patches tests are performed immediately by as many people as possible in development or personal workstations and once we are satisfied the individual patch is rolled out.

Re:So how do you manage your Sun patches?

[rtfm]

from the command line...

pprosvc -din

(tune -options for your needs). also, to get things like sunfreeware.com packages, check out pkg-get from http://www.bolthole.com/solaris/. supports, installs, upgrades, etc.

enjoy

Re:So how do you manage your Sun patches?

[Anonymous Coward]

"Bigadmins (with enough time on your hands to read slashdot), what do you do?"

I'm laid off now, have time to respond.

Before there was PatchPro, there was patchcheck

get it at http://sunsolve.sun.com/pub-cgi/show.pl?target=pat chk
(act soon , web page says they will discontinue it last week; I just tried it and got it.)

then get ftp://sunsolve.sun.com/pub/patches/patchdiag.xref
which is a flat file listing all patches and appropiate platforms.

run patchcheck , which is a perl script, which compares patchdiag.xref with the state of your system and outputs a nice list of possible updates.

then get patches by ftp sunsolve.sun.com
login: anonymous
cd patches

(some patches may require service contract, and nonanonymous login)

then just unzip and run like so:
patchadd 123456_69

Re:So how do you manage your Sun patches?

[MaoTse]

patchcheck is broken. Use (GPL-ed) pca.pl instead. It will let you control patches for you specific install easly.

Still, the Sun patching concepts amuses me. I hate the fact I have to make workorounds for the whole thing whenever I add a single additional SUNW package.

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:Workaround plus bad hyperlinks

[Anonymous Coward]

Something has to modify /etc/password (and/or the secret version if shadowing is used). Those files are owned by root, hence the executable must be setuid to root in order to modify those files.

Having a daemon do the updates is no good either, as the daemon needs a way to authenticate the caller. So the caller needs to be trusted in some fashion, i.e. setuid to root.

Re:Workaround plus bad hyperlinks

[Random832]

in the set-up you describe, the daemon should authenticate the caller ('client' would make more sense, since presumably the daemon is running all the time, not being called by the client program) by checking that its uid is that of the person whose password is being changed, not that it's root. why do you have to be uid root to be "trusted" to change a user password?

Re:Workaround plus bad hyperlinks

[Too Much Noise]

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.

really now ... what if your password expires and trying to change it with ... err ... passwd ... gives you a nice error - access denied message? someone running passwd won't be able to do anything. Yeah, that takes care of eliminating the privilege escallation issue, but it kills the patient in the process.

the 's' bit is there for a reason - the user has to be able to modify its password hash in /etc/shadow which is only read/write by root! sudo is a moot point if all the users have do be allowed to do sudo /bin/passwd ... and su, you'd have to be joking.

your solution only works if you can't patch the box and won't be adding any users, don't have password aging enabled and so on. Pretty narrow. Luckily, there is a patch from Sun :-)

Re:Workaround plus bad hyperlinks

[diablobynight]

That's what happens when you slashdot a server. The links go down. or it takes six years to retrieve a post, why don't you guy set up a slashdot mirror that people can upload to, so that the first guy can download the file, upload it to a server pool, and then post the link from a slashdotlink.com domain or something. I am sure their are lots of nerds on this site willing to mirror the upload site, and just use DNS to point to multiple systems, and whenever one is down it will go to the other one, proxypass in apache could do this, as well as other programs.

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:Nothing about the freebsd tcp/ip stack flaw?

[chooks]

Haven't you heard? *BSD is dying .

</flamesuit>

Re:Nothing about the freebsd tcp/ip stack flaw?

[Spy Hunter]

Maybe I'm just not a big enough open-source fanboy, but IMHO a local root exploit in Solaris is a much bigger problem than a denial-of-service attack on FreeBSD. One problem can cause security breaches in important systems that are assumed to be secure, leaking sensitive information, passwords, etc, and the only way to be sure your multi-user system is still secure now is to wipe it and reinstall. The other problem can temporarily disable your webserver.

local root vuln

[shird]

Huh? There are millions of local root vulnerabilities under *NIX, unless you can exploit this without first authenticating (eg. entering a very long username - without actually knowing a valid one), this is no different.

The capability and number of local root vulnerabilities under *nix makes me laugh at those who think Windows is more vulnerable to e-mail bourne viruses and tojans. Because in reality, it isn't.

Under Windows, a trojan is less likely to gain admin status and wreck your other accounts or data, because there are so few local exploits. Under Linux etc, a trojan has hundreds of avenues of attack to gain root status and stuff up your system much worse. Share your computer with your mum, she downloads some dodgy attachement, it gains root access and wrecks your account too. doh.

Re:local root vuln

[Anonymous Coward]

stupid fuckin zealot mods. Read the post and stop reading the bloody propoganda.

you exaggerate

[Stallmanite]

He is talking about the rights of the user vs rights of the owner, on public machines. Stores, for example, have owners, but they also public places. The rights of the customers are balanced against the rights of the owners.

Re:you exaggerate

[geoffspear]

Yes, and if he had his way, the customers would all have root access to the computer that's storing my credit card number after I make a purchase at a store.

this is not haiku style

[Anonymous Coward]

this isn't haiku style at all. it's lame, if you were typing on lynx with a tiny terminal or you are blind and have your fonts turned way up I'd understand, but you don't. you made an obvious attempt to be different, and therein lies your sameness. good day.

Re:OPEN SOURCE = GARBAGE. PROOF!!

[Anonymous Coward]

Well, if Solaris isn't "Opensource" I guess I will have to destroy
my archives of the source on cdrom here.
There is a difference between opensource and GPL.
Solaris is most certainly opensource.

Too easy...

[KillerHamster]

You're worried you may have a script kitty?

Re:Too easy...

[ArghBlarg]

Oh, if I only had mod points today.. :-)

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:The solution is simple ...

[Anonymous Coward]

And when an exploit for freebsd is released, you simply advocate everyone change to yet another OS after that? That's a great idea, just change OS' every time there's a problem.

At least..

[Raven42rac]

At least we disclose our vulnerabilities and patch them quickly. Compare *nix/OS X patches and vulnerabilities to Windows vulnerabilities. It will be a matter of "a buffer overflow could happen in this program, although no one has exploited it, and may not be able to, it could happen, so here is the patch, and here is the code" versus "this vulnerability will share everything on your hard drive, delete random digits from your spreadsheets, spread itself to all of your contacts, hit on your sister, rape your dog, tell bad jokes, and eat all your food in the fridge. We could have told you about this six months ago, but you know what, bite me, what do you paying customers know anyway?".

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:Patch links broken?

[mzs]

108993

113476

They are zip files, just extract them and follow the instructions inside. But are you really going to trust some links on slashdot? The way I found these is I went to sunsolve and searched for 108993 and 113476 in PatchFinder.

Re:Patch links broken?

[doc_traig]

But are you really going to trust some links on slashdot?

Heh... well, when I mouse over the links, they look clean, and I'm not using IE, so they're probably okay......

But the answer is no, I suppose. :)

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

Look at the 'submitted by' user name...

[mzs]

'so-1997-and-1994' should give a hint that these are not rampant vulnerabilities in solaris, though there are what -- probably six or so vulnerabilities a year related to PAM on various systems. I think the submitter was not bashing solaris, so much as pointing out a vulnerability that so far has only showed-up in CIAC (a little read and usually slow security news bulletin run by the DOE) and patches with their associated docs from Sun.

The thing is that authentication and PAM is just so complicated that effectively exploits of the passwd command show up with some regularity. A more seasoned admin than I here at work commented that this feels like 1982 all over again. I do agree that if there was a similar story like this submitted about linux, it would probably be rejected and not make front page news, though.

See other OS's do have issues

[Anonymous Coward]

Don't kid yourself people

it's slashdotted

[Joe_NoOne]

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

Re:Slowlaris is Dying!

[mcdade]

I love how people have no idea how much certian hardware is used can make comments like this. How can Solaris be dying when they are planning a Solaris10 release? you don't really do that with dying software.

Anyways, it's been out for X86 for atleast 6 yrs that I can think of , it's a bit sketchy and requires very specific hardware (this is not linux kids) but then again it's pretty solid as as system. Secondly on the sparc hardware, it drives much more then just a simple pc.. people that have never seen a real system enviroment don't understand the hardware levels required to drive multiple processors, and terminals and substain throughput to every device. We drive about 100 terminals off of a system with 12 processors and 8Gig of ram, it uses 4 Gig back to the switches to make all this happen. These machines can take a slashdotting, since they can handle students writing bad code with recursive fork()'s ... load hit 88 one day.. try doing that shit with a normal PC ..

Some people don't understand that the High end stuff is very different then their dinky little linux box you have at home that gets 100 web hits per day. Real machines cost money and they are build like a beast..they still are totally solid and use backplane technologies to attach system boards.. oh and they weigh a shitload.

-b

Re:User space part of Solaris gives Un*x a bad nam

[mzs]

Why was this troll modded-up?

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.

Yes I have once run into a bug in awk with escaping characters on solaris, the thing is that you get three awk commands, so I just used a different one.

What is the bug in grep that you allude to? Sure GNU grep has more options, but GNU loves to name them --foobarbaz so that you 'need' command line history and editing.

Solaris supports unified diffs since version 8 or 9 but people like me accustomed to solaris can't wrap our heads arround it and like context diffs better anyway. But patch files on the net are usually in unified format... Personally I dislike the bug in in GNU diff that does not give minimal diffs unless you ask it to (option --minimal believe it or not) so it really does not behave like the shortest-common-subsequence diff algorithm that is taught as the example for dynamic programming at university.

No command line editing in the default shells? I personally like ksh on solaris, maybe the up arrow does not work by default or something, but it uses similar commands that the shell on the embedded systems I maintain do.

I agree the vi included in solaris is krufty and old, but it will get you out a bind if you need it and prefer it to using ed. Good luck using vim or emacs when you are in trouble. Vim comes on the freeware CD as well, so it is a breeze to install. The same is true for all of the other examples you gave.

This is an article about security, why was this troll fed? Moderators?

Re:OPEN SOURCE = GARBAGE. PROOF!!

[Anonymous Coward]

Solaris certainly isn't open source, you need to pay $$$ to get the source, you can get the source to Windows the same way (shared source) Gasp... Horror...

Re:User space part of Solaris gives Un*x a bad nam

[Anonymous Coward]

You might be right, but sh and csh should never be molested like it is on Linux, sh should be properly POSIX complient, not just bash in disguise.

bah

[ShadowRage]

you dont need to reinstall your system, just get a rootkit checker for solaris.

Re:User space part of Solaris gives Un*x a bad nam

[mzs]

Agreed, I cannot tell you how horrible it was to change all of my scripts to use the pwd command instead of the pwd shell built-in all because bash disguised as sh likes to treat symlinks 'special'.

Just a local root

[bangular]

I don't use Solaris or really care for it, but...

It's just a local root vuln. That's not really a huge deal. I venture to say that at least 95% of *nix systems have a local root vuln and their admins don't know about it. Not that they don't matter, it's just they aren't the end of the world. The only sititutations that this would be exploited is if it's being used as some sort of shell server, or if someone exploits a remote vuln. and gets regular user access, and uses this to get root.

But! Most *nix systems already have a billion other local root exploits because they happen all the time. The last few 2.4 series kernel updates were because of local root's. Anything that runs suid is potential for a local root.

Re:Slowlaris is Dying!

[thebes]

Thanks for the MS link. Almost forgot there for a second. *whew*

Re:User space part of Solaris gives Un*x a bad nam

[Militant Apathy]

Don't forget packet filtering. Solaris has no native firewall -- the excellent IPF is a third-party add-on. The "out of the box" installation is almost unsecurable.

Then fire the admins....

[jotaeleemeese]

There is no reason for 12000 people poking around in servers.

Re:Then fire the admins....

[anno1a]

It being a technical university the users often need a lot of computing power. The system is set up with about 300 dumb clients (sun ray terminals) connected to a smaller server (running Solaris). All the heavier programs must be executed from the cpu servers (running Solaris), thus the students have access (heavier programs ranging from mozilla to matlab). The service the servers provides is computing power, so there certainly is a reason for everyone to be poking around in there.

Re:User space part of Solaris gives Un*x a bad nam

[Anonymous Coward]

Solaris does have a firewall. It is called Sunscreen.

It used to be spearate in a free "lite" version, but is now integrated in Solaris 9 or Trusted Solaris 8.

Re:Slowlaris is Dying!

[Mr. Piddle]

Are you referring to Windows 2000 Datacenter Edition?

Insightful? Yeah sure.

[jotaeleemeese]

Just for starters, ksh has been available for ages, and for the gnu lovers, Solaris has many utilities packaged by themselves and freely available.

Give me a fscking brake....

Re:User space part of Solaris gives Un*x a bad nam

[Mr. Piddle]

You are a troll.

Solaris offers several versions of userland utilities under /usr/bin, /usr/ucb, /usr/sfw, and /usr/xpg4 depending on what bugs you want.

Like you say, if you want more of GNU's bugs, there is an open-source CD that installs under /opt/sfw. There is also sunfreeware.com.

Solaris userland is actually not bad at all, but since you are probably a person who grew up in the GNU commune, you must think it really is right for vi have all sorts of fancy highlighting and rendering capabilities. Do you worship the autoconf god?

HOLY MOLEY!

[Anonymous Coward]

you mean unix has bugs?

Re:User space part of Solaris gives Un*x a bad nam

[Mr. Piddle]

For firewalling, it is probably just better to use OpenBSD or a dedicated Cicso box. Solaris really shines on servers and workstations.

Re:User space part of Solaris gives Un*x a bad nam

[Anonymous Coward]

Sunscreen has been bundled since 8. If you just want a host-based firewall it does the job admirably. If you want a full-on firewall, buy a firewall, or use OpenBSD maybe.

Medium my arse!

[Pan T. Hose]

VULNERABILITY ASSESSMENT: The risk is MEDIUM. A local unprivileged user may be able to gain unauthorized root privileges.

Yeah, right, medium. It is just a root exploit after all... Medium my arse! The fact is that the exploit has been circulating for quite some time now on irc and freenet. And are we supposed to believe that it was just an accident that a god damn root exploit has been included in the freaking passwd? Have you seen the source code of this thing?! An anonymous friend of mine has told me that there are quite a few strange lines of code not only in Linux. But guess what? It's quite hard to get Solaris source code to audit and patch it yourself, unless you have some ties to the underground. Medium... Yeah, right...

workaround

[bl8n8r]

why not rm /bin/passwd until sun gets a patch out.

Re:workaround

[Tpenta]

You didn't read the post did you?

Nor did you even bother to tread the Sun Alert.

Why should there be a wrokaround, WHEN THERE IS ALREADY A PATCH?

Tp.

I've never understood this

[spitzak]

Technically, the "nice ruler" could just as easily tell someone both a wheel account password and the root password, so I don't really see what the wheel group does that is worse for RMS than just the secret root password.

Conversely to other arguments against RMS here, I worked at Sun where everybody had a root password to their desktop machine. You could mess with it all you wanted (though if you screwed it up enough that you had to go to systems to fix it they were mad at you). Having root access to one box had nothing to do with getting root access to any other box. This scheme was incredibly useful and quite safe.

Where I work now, I don't have root password. If you do have root you have it to every machine. I constantly have to ask somebody else who has permission to fix things on my machine, and they have to be careful, for instance if they get confused about what they have rsh'd to they will screw up the wrong machine.

What RMS was complaining about is similar to home Windows users having a system with a correctly-working Administrator account that you must use to install or change software, but only Microsoft has the password and they run it remotely.

Microsoft sues Sun

[shaark78]

This just in, Microsoft is sueing Sun for copying their password changing code. The proof? Microsoft claim that since the code has security holes it must be their code.

wait a second

[diablobynight]

Linux doesn't have any security problems. Or at least that's what they always tell me when I am patching my XP, AMD machine. Build a Linux, Intel machine and you'll never have a problem.

So this is impossible. Nothing can happen to Linux, certainly, not a ROOT security exploit.

I refuse to believe, this is Slashdot, where Linux reigns supreme and the all powerful gods of modding, will mod you down for even suggesting a linux box has a vulnerability.

What's passwd(1)?

[Brian Kendig]

What's 'passwd(1)'?

I mean, I understand what it means to see 'passwd(1)' on a man page; that means the documentation for 'passwd' is in section 1 of the manual. But how can you say you have a vulnerability in 'passwd(1)'?

Isn't that like saying you like the TV show Angel(8pm) or that you want to go work for Sun(UltraSPARC)?

Re:What's passwd(1)?

[RaymondRuptime]

I suppose the point is to help the headline reader distinguish between the passwd command (man 1) and the passwd library function (man 3), as well as the passwd file format, headers, etc. (man 4,5). I didn't find it confusing at all.

Re:User space part of Solaris gives Un*x a bad nam

[mi]

Why was this troll modded-up?

Can't trolls be insightful, too? No I was not trolling. I'm just frustrated with Solaris and the number of steps it takes to make a command line on it helpful and convenient. The second I saw a subject of Solaris raised, I couldn't contain myself. Evidently, the "silent majority" of moderators feels likewise :-)

the thing is that you get three awk commands, so I just used a different one

That's my point! I unknowledged the availability of better awk, but it is annoying, that the good one is not the default. And "just use a diffeent one" does not cut it, because I want to change the default not only for myself, but for the 40+ other users... And there is no sure-fire way to change the environment (PATH, LD_LIBRARY_PATH) for all users, the way you can on *BSD through /etc/login.conf (/etc/profile and friends are not quite the same).

What is the bug in grep that you allude to?

None -- just lack of features, like -A and -B.

so that you 'need' command line history and editing

You do need them. If not you -- your users. If you re-read the subject of my original posting, I'm talking about "giving Unix a bad name". It is not among the ubermen, who pretend to not need to edit the command line. It is among the regular users, who anknowledge the fact, that they can make a type and don't want to retype the whole command (after Ctrl-U) or the whole word (after Ctrl-W -- if they even know about these shortcuts). Backspace is on the keyboard -- why does not it work by default?

The computers are many times more powerful today, than they were, when first versions of Unix were written. The utilities included in those versions grew features and fixed bugs during these years. Solaris is unforgivably slow in incorporating those improvements. That's my point.

Solaris supports unified diffs since version 8 or 9

# uname -a SunOS
kermit 5.8
Generic_108528-29 sun4u sparc SUNW,Sun-Fire-V440
# diff -u /dev/null /dev/null
diff: illegal option -- u

May be, version 9 finally has it -- after, what, 5 years of it being in BSD and Linux?

vi included in solaris is krufty and old, but it will get you out a bind if you need it and prefer it to using ed.

Well, ed will get you out a bind too, for that matter. It is just easier with vi. And even easier with BSD's nvi (no licensing problems -- why not make it a standard?)...

it is a breeze to install. The same is true for all of the other examples you gave

Again, I aknowledge the ease of modifying the defaults. It is having to do these modifications, that annoys me. Why? Who is it, who honestly prefers sh over ksh (the modern version) or bash as his/her login shell (I don't like the scripts relying on bash-isms either)? Who wouldn't prefer the nvi over Solaris' vi any day? Who would reject the ability to produce unified diffs on occasion, even if context diffs are her/his personal preference?

Mr. Piddle continues:

/usr/bin, /usr/ucb, /usr/sfw, and /usr/xpg4 depending on what bugs you want.

I want none of the bugs and all of the features. Thank you -- I expect nothing less from a "commercial grade" operating system.

Solaris userland is actually not bad at all, but since you are probably a person who grew up in the GNU commune, you must think it really is right for vi have all sorts of fancy highlighting and rendering capabilities. Do you worship the autoconf god?

In what way is it "not bad at all"? In absolute terms? May be. In relative terms, however, every common Unix utility offered by Solaris is at best equal to, but usually -- worse than its counterpart in a *BSD or Linux offering.

autoconf has absolutely nothing to do with this. You know it and I know it -- don't switch the issues.

Re:User space part of Solaris gives Un*x a bad nam

[MaoTse]

Yes, I do worship the autoconf god. Like it or not - it is one of the main reasons for unix software viability nowadays.

And please don't troll on sent-god Sun userland tools. Have you ever used Solaris default vi in a Eterm window ? What do you do with patches applied previously when you install additional SUNW packages ?

This is good software but I have no doubt Sun forgotten of several issues last 10 years or so.

Re:OPEN SOURCE = GARBAGE. PROOF!!

[Anonymous Coward]

so do you actually know the difference between open src and free src ..... there is a difference ......

Re:User space part of Solaris gives Un*x a bad nam

[Mr. Piddle]

Yes, I do worship the autoconf god. Like it or not - it is one of the main reasons for unix software viability nowadays.

I've generally had mixed results with autoconf and especially libtool. They are widely abused, often ignoring my environment variables and sometimes even writing broken makefiles. They are complex enough that debugging them is a nightmare. There has been more than one occasion that I wished for a simple file with a simple list of dependencies that I can simply say "lib XYZ is here, dammit."

Have you ever used Solaris default vi in a Eterm window ?

Eterm? I generally have few problems with Sun's vi, and those problems are almost always related to terminal type issues over telnet to/from Linux.
Terminal types are a UNIX problem, not just a Solaris and Linux problem.

What do you do with patches applied previously when you install additional SUNW packages ?

Additional SUNW packages typically get installed under /opt. They generally won't conflict with operating system patches that go under /kernel and /usr.

Re:User space part of Solaris gives Un*x a bad nam

[MaoTse]

I've generally had mixed results with autoconf and especially libtool. They are widely abused, often ignoring my environment variables and sometimes even writing broken makefiles. They are complex enough that debugging them is a nightmare. There has been more than one occasion that I wished for a simple file with a simple list of dependencies that I can simply say "lib XYZ is here, dammit."

Well, my experience is diffrent. Sendmail m4 build system experiance counts ;-). AFAIK Sun still recomnds hand editing of the cf file ;-))).

Eterm? I generally have few problems with Sun's vi, and those problems are almost always related to terminal type issues over telnet to/from Linux. Terminal types are a UNIX problem, not just a Solaris and Linux problem.

C'mon, solaris terminfo is just broken. That's a reason for lots of problems. vi is unusable if you're on not on serial.

Additional SUNW packages typically get installed under /opt. They generally won't conflict with operating system patches that go under /kernel and /usr.

Not true. SUNW packages rarely install in /opt. But it's not the point. What I meant is you can't really get them patched unless you manually go thru all your patches and uninstall them (if you can ;-) and install once again.
Cheers,

Re:User space part of Solaris gives Un*x a bad nam

[IvyKing]

Don't forget packet filtering. Solaris has no native firewall

Ummm - I think it is called "Sunscreen" or something to that effect. IIRC, it allows you the option of passing traffic to firewalled hosts without address translation.

If you just want to protect the host, then you can define secuirity associations for each port - including requiring IPSEC connections. Solaris has had native IPSEC support for several years (albeit with rather sucky documentation).