Local Root Vulnerability in passwd(1) on Solaris 8, 9 283
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."
There but for the Grace of God go I (Score:4, Interesting)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Informative)
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 inst
Bzzzt! Wrong! (Score:5, Insightful)
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:There but for the Grace of God go I (Score:2, Informative)
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 (Score:2, Insightful)
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 (Score:3, Informative)
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 (Score:5, Insightful)
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 (Score:2, Interesting)
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
Re:There but for the Grace of God go I (Score:3, Insightful)
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 Li
Workaround plus bad hyperlinks (Score:5, Informative)
How about "chmod ug-s
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 [sun.com], and if I click on the links to get patches,....
Sparc
Solaris 8 with patch 108993-32 [sun.com] or later
Solaris 9 with patch 113476-11 [sun.com] 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:There but for the Grace of God go I (Score:3, Insightful)
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 'caus
Re:There but for the Grace of God go I (Score:3, Funny)
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 (Score:3, Insightful)
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 wor
Not surprising (Score:5, Insightful)
Re:Not surprising (Score:5, Insightful)
Re:Not surprising (Score:5, Informative)
A quote from the changelogs of Slackware 9.1, just to offer a different perspective:
PAM (Score:5, Insightful)
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 [stacken.kth.se])
Re:PAM (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:4, Informative)
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:
Re:PAM (Score:5, Informative)
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 [sun.com]:
Risk assessment (Score:5, Interesting)
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 (Score:5, Insightful)
Re:Risk assessment (Score:2, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Interesting)
Re:Risk assessment (Score:2)
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 (Score:3, Informative)
Re:Risk assessment (Score:5, Interesting)
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 (Score:2, Redundant)
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 (Score:3, Insightful)
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
Re:Risk assessment (Score:2)
Re:Risk assessment (Score:2, Insightful)
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 (Score:5, Interesting)
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 (Score:5, Insightful)
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 (Score:2)
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 stron
Re:Risk assessment (Score:4, Insightful)
I can't think of a case in which one can run
Re:Risk assessment (Score:2, Insightful)
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 (Score:2)
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 (Score:5, Informative)
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 [bpfh.net].
Re:Risk assessment (Score:2)
Yeah, good point. 'Course if you can do that on a box, it's got more fundamental problems to worry about...
Re:Risk assessment (Score:2)
Re:Risk assessment (Score:2)
Re:Risk assessment (Score:2)
Re:Risk assessment (Score:4, Insightful)
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 (Score:4, Interesting)
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 (Score:4, Insightful)
Re:Risk assessment (Score:2)
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 (Score:5, Interesting)
Re:Risk assessment (Score:2)
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 (Score:3, Interesting)
Thanks Tim, here's some spam (Score:5, Funny)
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 (Score:2, Funny)
What? How does this make sense? (Score:2, Funny)
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? (Score:5, Funny)
"Won't somebody please think of the pedants?!"
Solution (Score:2, Funny)
Re:Solution (Score:3, Interesting)
Re:Solution (Score:5, Funny)
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. [gnu.org]
Typical RMS.
Security is a touchy issue for RMS (Score:5, Insightful)
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.ht
http://catb.org/~esr/jargon/html/os-and-jedgar
Re:Security is a touchy issue for RMS (Score:3, Interesting)
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 approva
Re:Solution (Score:2, Interesting)
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 (Score:3, Informative)
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"...)
solaris bashing? (Score:4, Insightful)
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? (Score:4, Interesting)
> "Which is a moot point as everyone knows you don't get security holes in linux"
really? http://www.linuxsecurity.com/advisories/index.htm
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? (Score:2, Informative)
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 [sun.com]
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? (Score:5, Funny)
Re:solaris bashing? (Score:2)
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" he
Finally... (Score:5, Funny)
Re:Finally... (Score:2)
Ok , so hows it done? (Score:2, Insightful)
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? (Score:3, Interesting)
There is a reason why most security-teams allow vendors to fix stuff before going full-disclosure...
Re:Ok , so hows it done? (Score:4, Insightful)
Further Proof (Score:5, Funny)
- J Allchin
Judge this based on what? (Score:5, Interesting)
flaw isn't explanied in detail. Without
more explanation, however, there is no
way to tell how serious this really is.
What's yellow and dangerous? A canary w/ root
password.
In my understanding of systems security,
every security issue may be serious, but
this one is definitely less than serious.
A system that has no test:test accounts or
guest logins, with all non-privileged users
somehow known and/or affiliated with a systems
administrator, chances of a major breach are
slim.
Incidental damage by a less skilled
non-privileged user is another matter, though;
likely and depending on the circumstances -
reminds me of a poll once taken: would you trust
your significant other with your root password?
I hope this haiku style editing doesn't offend anyone.
Big deal? (Score:5, Insightful)
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? (Score:3, Interesting)
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? (Score:2, Insightful)
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 partic
Intelligent advertising system? (Score:5, Funny)
"SUN MICROSYSTEMS TECHNOLOGY HELPS TAKE YOU PLACES YOU'VE NEVER BEEN BEFORE."
Places I've never been before... Rootland?
Solaris is secure (Score:2, Informative)
I've been using Solaris (and before that SunOS) for years on my company's servers and there's never once been a root exploit. As with any OS, you just have to keep it patched.
Concerned (Score:3, Funny)
fingers crossed, suspiciously stares at kitten....
Too easy... (Score:5, Funny)
Nothing to see here (Score:5, Insightful)
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.
How are you gentlemen? (Score:2, Funny)
phew (Score:2, Funny)
I wuv you CDE.
User space part of Solaris gives Un*x a bad name (Score:5, Insightful)
The kernel may be great and uber-stable, but the user-space utilities shipped with the OS are ancient and full of bugs long ago resolved in *BSD or Linux offerings.
I am talking about awk, grep, diff (still no unified diffs!) and the like. The default shells -- sh and csh -- do not even allow for command line editing. make is outdated. vi borks if you extend your xterm too wide.
Sure, you change the login shell to bash or tcsh, you can install the GNU utilities. Or BSD, for that matter (I ported FreeBSD's make(1) myself to use the bsd.*.mk files). But then, hey. you can even customize Windows to be almost like Un*x...
The "out of the box" installation should be -- and can be -- much better...
To bring this back on topic, it seems to me, the major thrust of the Solaris development is on kernel. The user space side -- including the passwd(1) -- is neglected.
So how do you manage your Sun patches? (Score:5, Interesting)
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?
Nothing about the freebsd tcp/ip stack flaw? (Score:5, Insightful)
But why is there nothing about the highly more critical and remotely exploitable tcp/ip denial of service discovered in all versions of FreeBSD ?
This will linger on for quite a while... (Score:5, Informative)
Patch links broken? (Score:4, Interesting)
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:Slowlaris is Dying! (Score:5, Informative)
Re:Slowlaris is Dying! (Score:4, Informative)
Re:Rule of thumb.. (Score:2)
No, wait
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!
Re:Sigh... (Score:5, Funny)
Re:Sigh... (Score:3, Informative)
Re:Sun FUD on Security (Score:2, Insightful)
Quit hoping you will get modded up for your unabashed Sun bashing.
Re:so how does on go about exploiting this... expl (Score:5, Funny)
This is left as an excercise to the reader.