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