[lug] root password

[Rob Nagler]

Kevin Fenzi writes:
> Yeah, you are mostly correct, however anoyingly root can bypass the
> "good password" checks on any of the Linux distos I have seen. This

Root users can also:

    chmod u+s /bin/sh

We are not talking about root level security.  Don't give root (su or
sudo) access to people who don't understand security.

> Of course you need to make sure your machine with keys on it is
> secure.

That's the problem.  No computer is secure.  Security is not an
absolute, it's a continuum.

> Can you expand on this? AFAIK if you login to 'open' with a ssh-key it
> makes you no more vulnerable than if you logged in with a password.

The problem is a remote to local to remote exploit.  If you leave a
key on a machine, you are leaving a link open to a local exploit.  The
same problem occurs if you use the same password on an "inside"
machine as the "open" machine.  Or, worse, the user whose account is
exploited, has sudo access.  Once you are on the "open" machine, you
copy /etc/shadow to your thousand++ windows boxes that have been made
available to you thanks to Microsoft CrackGrid(tm).  MCG(tm) can crack
any password in /etc/shadow in minutes, if not, seconds.  Whether it
is /etc/shadow or /home/*/.ssh/id_* doesn't matter, they are all
crackable on any "Grid", because the bandwidth requirements are so
low.

> Not sure what you are saying there... anything that runs on "open" if
> it's compromised can be assumed to be sniffable by the compromiser.

Not exactly.  SSL is a complex protocol that involves constant key
changes.  The initial handshake is via public keys, and the rest is
via dynamically generated shared key(s).

If I ssh into trusted host A via (un)trusted host B, I can set up
LocalForward to (un)trusted host C via B.  I don't particularly care
if the communication is open to the world, because I am encrypting
traffic on A destined for C with C's public host key, which only C can
decrypt (in real-time).  B sees the same stream of data that my
insecure wireless hub sees when I ssh to another host.

Now, someone can always spool an SSL connection, and crack it later.
However, that involves quite a bit of cpu, disk, access, and
technology.  They would have to compromise the sshd (or wireless net :-)
in such a way to spool the data without disturbing the stream.  Once
the session is spooled, you have to get it off the box, and that may
require a lot of bandwidth.  It is doable, and I'm sure the US
government has this technology.  However, your average script-kiddie
doesn't have this technology.

The assumption I'm making is that if a server like sshd is restarted,
you'll know about it.  It's an easy check, and even the government,
won't really know how you are checking that sshd has been restarted.
The cache file would be too complex to automatically sniff out.
Therefore, you'll know the exploit has happened.

A quick root exploit that simply takes advantage of a known hole in a
daemon can spool off /etc/shadow and /home/*/.ssh/* instantly, and be
gone.  You might never know it happened.  However, the cracker will
now have an authorized_keys file for each user that you let have
authorized keys.  From that point on, it's a simple problem: run a
cracker program that is available to script-kiddies on these files
offline on the Microsoft CrackGrid(tm).

> You should indeed only run ssh-agent on your single inside secure
> machine. If the machine that has ssh-agent running on it is
> compromised you are lost.

My machine is a laptop.  It's not secure, and indeed, I run the
largest variety of insecure apps on it.  When I run ssh, I run it as a
regular user -- the same user I run Firefox, Microsoft Word, Bitpim,
Photoshop, Skype, etc.  All of those programs are bug ridden, and it
would be trivial to sniff my ssh-agent.

I have a better chance on my bug ridden laptop if I require the
cracker to sniff my password by compromising the kernel or ssh than I
do if I run ssh-agent.  The same logic applies as above.  It's much
harder to capture a live password via a sniffer than it is to search
the file system for a couple of well-known files and/or processes.
ssh-agent is a known process.  All a Firefox exploit has to do is look
for ssh-agent and attach to it to get the decrypted private key.
That's an order of magnitude easier than planting an "ssh" somewhere
in my path that contains a sniffer (although that's depressingly easy
to do, also).

> Yeah, those are often contradictory issues... ie, all systems have
> diffrent password, and you should only have a few you can remember.
> SSH-keys help there.

No. All systems do not have a different password.  That's impossible
for humans to manage in our distributed world.  Different classes of
systems have different passwords.  I don't give the same password to
Amazon.com as I do to Mailman, for example.  Amazon.com has my credit
card, and Mailman doesn't.  If someone compromises my Amazon.com
password, they can login to buy.com and buy things, too.  However,
they can't login to any of my servers (via the web or ssh) with that
password.  (I use the same password for ssh and Mailman. ;-)

Rob