From Fedora Project Wiki

< FWN‎ | Beats

(Imported from MoinMoin)
m (1 revision(s))
(No difference)

Revision as of 16:32, 24 May 2008

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers


By far the biggest event to happen last week was the OpenSSL mess. Most people have heard about this in some manner, but there is a lot of misinformation about all this, so I shall try to clear some things up.

What Really Happened

In September of 2006, Debian patched their version of OpenSSL in a manner that greatly reduced the entropy used in the OpenSSL random number generator (RNG). This is known as "seeding" the RNG. Computers are quite bad at doing "random" things. They are designed to be predictable, so when we need something like a random number, how is it done? There is an algorithm called the <a href="">pseudo random number generator</a> that generates a sequence of numbers that appears to be random. The randomness is determined by the initial seed. If you know the seed, you can easily determine the random numbers it will generate. What happened in this OpenSSL patch, is that most of the entropy used in the seed was removed, so basically only the process id (which is an integer between 0 and 32768) was used as the seed. The problem then becomes, that an attacker knows there are only 32768 possible seeds used in random number generation. For a fast computer, 32768 is a very small number.

What does it all mean

Right now, the program getting the most attention is SSH. SSH is affected in a couple quite different ways, all being quite serious.

The first is SSH keys. When you generate an SSH key, a random number is used to generate the key. If the random number used can be predicted, it's possible for a remote attacker to generate an exact copy of the SSH key. There are currently attempts underway to generate all possible SSH keys, which could then allow attackers to easily log into vulnerable accounts. Once a weak key is generated, it doesn't matter if it's used on a system with a properly functioning OpenSSL, the key is still weak and should be replaced. If you're not sure about your key, you should probably replace it.

SSH also uses something called a "host key" to identify a remote system to a user. The host key is used to ensure that the machine you are connecting is indeed the machine you think it is. If an attacker is able to generate a copy of the SSH host key, they can conduct a man in the middle type attack to steal sensitive data.

There is also the question about what happens if you've used a strong key on a weak host. This is an issue due to the way SSH works. Many of the steps involved in SSH authentication and data transmission requires good random numbers to work properly. That means that if you have a strong key, but use it on a system with a broken version of OpenSSL, it's possible that an attacker could capture the traffic and recover your private SSH key. If you only connected to (not from) a host with a weak OpenSSL, the data transfered could possibly be recovered, but your key should still be safe.

The Debian Wiki has a great deal of information about all this.