On Sun, Mar 03, 2002 at 07:23:09PM +0100, Michel Eyckmans (MCE) wrote:
Hello again,
Yes, so do I. But if you'd 777 ~/.fetchmailrc, fetchmail will not run:
Sure. But that is not the issue. The issue is that murphy dictates that
this kind of error happens on a friday evening, leaving the file open for
every passer by to read till you get back on Monday and find the time to
discover the problem and fix it. And then if this password also is your
login password (in my case: on the NT machines) and everybody in the
organisation knows for sure that it has to be the same...
Having used fetchmail several years, this has not happened even
once nor do I know anyone to which it has happened. Probability is
amazingly low and, correspondingly, is the likelyhood that anyone would
be "looking" for it to happen. Not a significant threat. I have yet
to hear of someone compromised in this maner. I would agree that, where
avoidable, passwords in configuration files are a bad thing, but encrypting
the configuration files is not going to solve the fundamental problem either.
Your bigger threat is sniffing, especially in the environment you just
described where someone sniffing your password from a POP3 session can
reliably expect it to be the keys to the kingdom for your Windows account.
Why even bother looking for it in files when it will be handed to you
on a silver plater across that wire?
As an aside, what happens with a fetchmail daemon? Does it stop working
too? Does it even notice in case the file itself is not chaged?
But as I understand it, you don't trust your root's, correct? Well,
I haven't said that. I have implied that people in general might not
trust their root, and have said that, independenty of whether I do,
my password selection "algorithm" is private information that should
be "for my eyes only".
If you can not trust root on your system you can not trust to
log into the system at all. Period. Root can trojan the login binary
or the pam library files to capture your login password. Game over.
He can install a keyboard monitor (ttysnoop) on you and capture everything
you type. Game over. You can't even trust ssh or pgp or any other
encryption in an environment like that. He can do this on Windows as
well as Unix.
dunno, but you do know that even if fetchmail would store the password
encrytped, it would be rather easy to sniff the password, don't you?
I know. But sniffing requires more effort than simply reading a file
that has been accidently chmod-ed by a badly written shell script (or
some similar such).
No, that's not true at all. Sniffing is pervasively simple and is
stock and trade in most worms and rootkits. Simple isn't even the correct
term. Trivial is the correct term. Simple is the term for sniffing
in a switched environment where you have to play tricks with arp cache
poisoning to defeat the switch. With the stock tools, that's even
simple. Sniffing is (outside of the arp cache poisoning tricks) an
entirely passive activity which does not require access to your system
and is almost impossible to reliably detect. File glomming requires
someone to already have access to your system be actively pawing through
it looking for misconfigured files. Not impossible, just not likely.
The likelyhood of someone sniffing a connection - very high. The
likelyhood of someone snooping around for an accidentally chmod'ed file
what won't work with the wrong permissions and having it stay that way
long enough to be tripped over - rediculously low. You have a much
higher threat profile from sniffing, to say nothing that it doesn't
even require someone to have access to your box like the file glomming
would.
In contrast to never having seen anyone compromised due to an
E-Mail password in a fetchmailrc file, I know of several very high
profile instances where sniffing has resulted in major compromise. RootShell
was compromised when a password was sniffed from the wire and it happen
to match their root password for their site (opps). They said that the
intruder busted in through ssh. Welllll.... Yes, he did. He used ssh
to bust in but he just happen to have the root password sniffed from another
system. :-) At a "black hat" conference a few years back, during a
"capture the flag" game, an OpenBSD firewall was raped because someone
telnetted to it and typed the root password over the wire. This
really does happen. Password in clear text over the wire are going to
get sniffed. Sometimes, even by accident.
I also know of numerous Windows accounts which have been busted
just by sniffing the wire with l0phtCrack. Newer versions of Windows
are better (NT 4.0 SP6 or W2K or better) but previous versions with
SSP1 (Security Service Provider version 1) are amazingly lame. We busted
several dozen accounts at my office, just to prove a point one time.
We snatched the Windows SAM database and busted every password out of
several hundred outside of two or three (the two of us demonstrating the
tools were both in the class that was NOT busted :-) ). Sniffing and
cracking are being actively pursued and viciously effective.
Note that I already agreed that the unencrypted sending is the biggest
problem, since that's why fetchmail would need to cointain the decryption
code in the first place.
Which totally nullifies any usefulness. If the password is
reversibly encrypted (which would be required for fetchmail to use it)
then someone can simple determine how fetchmail decrypts it. If you use
some form of symetrical key crypto, the attacker merely needs to determine
the key from the binaries. If you use public key crypto, it still amounts
to the same thing, the fetchmail binary must have the key to decrypt the
password. If you put a password on it, the attacker merely has to capture
the password when you enter it (recurse back to "do you trust root" and
"don't log into that system if you don't") and you are in the same situation
as if you had to enter the password each time. You might consider using a
smartcard or other form of extended token system, if it's that bad.
To nullify the real threat (sniffing clear text passwords on
POP3 or IMAP) switch to the SSL encrypted versions of those services.
Since fetchmail AND Exchange AND Outlook support SSL encryption on BOTH
of those services, you should have THAT covered. There are some other
alternatives, such as APOP and GSSAPI and kerberos, but they are
all pretty nasty to impliment and manage. I think there are also patches
to support these protocols over ssh, but that's a non-standard solution
and the SSL code has been in the fetchmail code base for a long time.
Final note... If you really have a wild hair about a clear text
password in the fetchmailrc file then encrypt the entire file with a
file encryption utility and only decrypt it when you need it (ala
loopback encryption, or LoopAES, or ppdd, or pgp). Stick it somewhere
it can be stored encrypted and then point a symlink to it. It doesn't
solve any of the problems if you don't trust root on your sysadmin (who
can read /dev/kmem and trojan your crypto utilities anyways) but if
it makes you feel good and covers your butt with your crypto-clueless
manager, then go for it.
One of my favorite comments from Bruce Schneier (Applied
Cryptography) goes "If you think cryptography is going to solve your
problem, you don't understand cryptography and you don't understand
your problem). Your problem is protecting your password on the file
system. Reversibly encrypting it in a way which fetchmail can
automagically decrypt it is NOT a solution to THAT problem.
Regards,
MCE
--
========================================================================
M. Eyckmans (MCE) Code of the Geeks v3.1 mce-at-pi-dot-be
GCS d+ s+:- a36 C+++$ UHLUASO+++$ P+ L+++ E--- W++ N+++ !o K w--- !O M--
V-- PS+ PE+ Y+ PGP- t--- !5 !X R- tv- b+ DI++ D-- G++ e+++ h+(*) !r y?
========================================================================
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(_at_)WittsEnd(_dot_)com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!