A lot of confusion has turned up about the
OpenSSL
insecure PRNG vulnerability in Debian and related systems. This is
an attempt to clear these up.
Which distributions were affected?
All distributions which pulled their OpenSSL changes directly from Debian.
Those are namely:
Debian Etch and Lenny, Ubuntu/Kubuntu/Xubuntu and related, grml,
Knoppix and
all living customizations and Univention UCS 2.0. Other Linux
distributions may also be affected.
Known not to be affected are: Fedora, Debian Sarge, NetBSD, OpenBSD,
FreeBSD, DragonFlyBSD, MirBSD, Gentoo Linux, Univention UCS 1.x, Red Hat
Enterprise Linux, OpenSuSE, SuSE Linux Enterprise, CentOS, pfSense,
m0n0wall, Sun Solaris 10 and prior and OpenSolaris.
What exactly is the problem?
Due to a slightly
misguided valgrind warning patch, the only “random” element
used in key generation and other random number generation processes by
Debian was the process ID. Since typical process IDs under Linux range from
0 to 65'535, there were only 65'536 possible different keys generated by
the OpenSSL toolchain, also including SSH.
This means specificially that an attacker needs only 65'536 attempts to
bruteforce a key generated by any Debian tool during this period of time.
The impact of this depends on the usage of the key: for SSH user keys,
it means that an attacker can impersonate the affected user and log in
as the affected user to any system where the key is in the authorized_keys
file. For keys used for certification and encryption, such as SSH host
keys and SSL certificates, an attacker can impersonate the affected SSH
or web server, and can potentially read currently running and recorded
sessions, depending on the procedure used for session key establishment.
How can I figure out if my key was affected?
Debian and Ubuntu have released
tools
for key analysis which scan for patterns of the vulnerable keys by
connecting to named hosts and looking into user's home directories for
authorized_keys files which contain the patterns. An updated version of
OpenSSH for Debian and Ubuntu now ships with a tool to automatically
discover and refuse the vulnerable keys.
My key is affected – what should I do?
The first point is of course to immediately update the affected packages
if you use a Debian derived system. Then, generate new SSH keys and replace
them on all systems where your old SSH keys are located. Replace them
as well on the servers of this nasty customer who left for the concurrence
– imagine what would happen if he found out that you left a vulnerable
SSH key on his host and that his host was compromitted by your negligence.
All affected OpenSSL certificates should also be revoked immediately. Generate
new certificates and let them be signed and re-issued through your CA.
Commercial CAs should let you reissue the certificate with the same Subject
until the end of the certification period you paid up to. Please note that
revokation is a critical step here, otherwise people might still impersonate
your old certificate which might, after all, still be valid.
Then make sure your infrastructure was not taken over by botnets through
an insecure SSH key. Check for rootkits as well while you're at it. If your
log host is affected, tough luck.
How urgent is this? Will I have to act immediately?
Yes, this item requires your immediate attention as there are already
botnets
out there which search for accounts with vulnerable SSH keys. The
question is not “Does someone care about me little Internet user?”
— these bots are out to compromise hosts and to send SPAM and malware
to other hosts. They don't care if you are an attractive target, they
attack anything they can find and try to send SPAM with it.
I have put my securely generated private SSH user key onto a Debian
system. Should I replace it?
Yes. On a Debian system, your private key was not safe during the last 2
years. The system may have been compromitted during that time, or someone
may even only have been eavesdropping your communication and have gained
knowledge about your SSH key. You should definitely consider it
compromitted.
I have put my securely generated public SSH user key onto a Debian
system. Should I replace it?
This depends. If your key is an RSA key, it is not compromitted simply
by putting the public key onto a server and authenticating against it.
The SSH 2.0 protocol, as described in RFCs 4252 and 4253, part of the
token being signed as challenge by the user is the “session
identifier”, which is a hash from the key exchange. This effectively
prevents replay attacks of authentication processes done using a
non-vulnerable SSH key, because the random material used as challenge
is not only controlled by the vulnerable SSH host, but also by the
non-vulnerable client. Thus, the data your SSH key has to sign as a
challenge is not vulnerable to the weak PRNG of the SSH server, and
thus cannot compromise your key.
This is however not true for DSA keys. DSA has a weakness when used
in the Diffie-Hellmann key exchange process, rendering it basically
uneffective. If the attacker gets hold of the random number used by
the Debian SSH server in the key exchange process, this can be used
to calculate the private DSA key from the public key with a complexity
of 216, being 65'536.
Summary
- Change any key pair generated using an affected version of the
pseudo-random number generator. This applies both to the user and
host SSH keys, and is of course also valid for certificates.
- If you have used a DSA key or certificate on a host affected by
the vulnerability, it must be regenerated.
- Assume that all data read from and written to a vulnerable machine
may be intercepted and/or tampered with, like if no crypto layer had
been applied in the first place.
- RSA keys used to authenticate to vulnerable hosts are secure.
Acknowledgements
Special thanks for this goes to Steven M. Bellovin, who took the time
to go through an analysis of this entire process with me and to clear
up my misunderstandings about the OpenSSH challenge-response procedure.
(Original source)
