Re: non-root password lookups? [LONG]
On Tue, 19 Jan 1999, Chris wrote:
> Can you explain what the problem with a auth daemon is? If there was a
> daemon listening on a system port then why couldn't local processes be
> sure that it is the real thing (since its the same machine anyway - if
> a skript kiddie can fake the daemon running on a system port then he
> has root anyway)? What am I missing?
In short: I can't see and never could see that a daemon to do that offers
me any protection over just having my crypt(3)ed passwords in /etc/passwd,
and could in fact be detrimental (see below). People who use stupid
passwords (names, birthdates, etc.) deserve what they get. If you need
more security than 56-bit DES passwords in /etc/passwd provide, shadow
passwords and/or rpc.pwdauthd (or a variation thereof) is _not_ the Right
Answer(tm) - some kind of one-time pad (OTP, à la S/KEY) or public/private
key encryption (à la PGP or ssh) is.
I suggest that this is growing somewhat off-topic for debian-mentors;
perhaps debian-devel is a more appropriate forum?
In long:
Let's pretend that you are the administrator for a small company's network.
There's a bunch of boxes, some more secure than others.
Scenario 1: You use the mail server on your desk as a workstation from time
to time. One day, Mr Cracker finds a vulnerability in the imapd on your
box. He crawls through it, and proceeds to trojanize /bin/login and
/usr/sbin/imapd. He is careful to not mess up the a/c/mtimes on the file.
Three months later, you upgrade imapd. Mr Cracker notices that imapd isn't
gathering passwords and stashing them in a safe place any more, so he
re-trojanizes it. Quite by accident, you notice that the imapd upgrade
didn't stick, and investigate - and find that your system has been
compromised.
How long has he been there? What has he been doing, other than gathering
passwords? How many users' passwords has he secretly obtained? He hasn't
managed to obtain _your_ password this way, since you never use IMAP, but
what about the boxes other people telnet/ssh to from your machine? Have
they been compromised? Time to reinstall everything and try again.
In Scenario 1, the cracker only trojanized imapd, and therefore only
collected passwords from users who used imapd.
Scenario 2: You use the mail server on your desk as a workstation from time
to time. One day, Mr Cracker finds a vulnerability in the imapd on your
box. He crawls through it, and proceeds to trojanize /sbin/rpc.pwdauthd.
He is careful to not mess up the a/c/mtimes on the file. Three months
later, you notice a suspicious file in /usr/bin that seems to contain every
password - even incorrect attempts - that's been typed on your system for
the last three months.
This time, _anything_ that uses passwords has been indirectly compromised,
and you're going to have a fun month reinstalling every server on your
network to make sure the cracker isn't hiding somewhere else on your
network.
<rant>
rpc.pwdauthd is a bandaid over making programs that access
/etc/shadow suid root or sgid shadow.
I'm not convinced that even /etc/shadow is necessary. Providing you have
even halfways decent passwords, you don't have a lot to worry about. If
you have people in Black Hats coming after you with the budget to build the
EFF's 56-bit DES cracker machine (or an even faster one), chances are that:
a) you're screwed anyway, or
b) you're sufficiently important that you've already taken every possible
measure to protect against compromise, like shutting off unnecessary and
superfluous services and using Real Encryption(tm), and sophisticated
monitoring systems.
It is a _lot_ easier to replace /sbin/rpc.pwdauthd with a trojanized
version than, say, to replace libc or system services, because it has a
_lot_ less moving parts. libc is a very good example of something with a
lot of moving parts - just recently, for example, I upgraded libc6 on my
home machine, which cased _every single program I'd compiled myself_ to
break. (__register_frameinfo, anyone?)
I concede that breakages like that are _rare_, but there's still enough
moving parts in libc that can be snapped off by accident to guard against
(IMHO) someone putting a libc with a trojanized crypt(3) in a rootkit.
(In fact, rootkits are a good way for cracker wannabes to be detected -
they typically contain programs that are sufficiently dissimilar to cause
major things to fail and bring the problem to someone's notice.)
We recently found that a server here had been compromised (via, it appears,
the imapd from Bo that somehow got missed when the machine was upgraded to
Hamm) _in November, 1998_. I only noticed it because I found an
unaccouted-for user in /etc/passwd. If he hadn't done that, but instead
trojanized /sbin/rpc.pwdauthd, who _knows_ how long he might've lain there,
undetected?
</rant>
--
Jeffrey Sean Connell | Networking/Telecommunications Engineer, GXC
ankh@canuck.gen.nz | PGP key at http://www.canuck.gen.nz/~ankh/pgpkey.html
---------------------+-------------------------------------------------------
Reply to: