Slashdot Mirror
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."
These days with files, nis, nis+, ldap, and different encryption schemes, passwd is a complicated program.
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.
. . . 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.
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.
>>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??
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.
. . . 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.
"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....
Yes, a single exploit makes his statements a lie.
Quit hoping you will get modded up for your unabashed Sun bashing.
"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
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".
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.
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.
Super Awesome Broadband
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.
Where is this stated?
/bin/passwd without having already logged in. Perhaps you are thinking of /bin/login?
I can't think of a case in which one can run
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.
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.
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.
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.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Except for remote logging... which is security 101.
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.
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.
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...
/ss
No passwords may seem strange to us, but try to try to keep in mind the context that created that attitude.
m l. htm l
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
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)
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.
In Soviet Washington the swamp drains you.
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 ?
{{.sig}}
There are no tiger attacks in my area and it's all because this rock I'm holding keeps the tigers away.
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.
"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?
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
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.
Vote in November. You won't regret it.
> 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.
/bin/passwd, and let the admins who have access modify their passwords as root.
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
Paul
[1] Guess where the problem appears to live?
http://www.pauldrobertson.com