Today I'm happy to announce the Open Source Software Security community. This project is an ongoing effort to manage security information in Open Source software by building on the collaborative foundation of the open source model. You can find the official announcement on the Red Hat News page, and the mailed announcement.
So the question has been bothering me for quite some time, how many times can I really write to one of these USB memory stick things before it finally dies. With as popular as the USB drive based distributions are becoming, I was wondering, how practical are these distributions. The stick used in this experiment is a 1G Sony Microvault USB Flash Drive.
I'm going to see how many times I have to write to this before it dies. (more after the fold, this is a very long post)
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 pseudo random number generator 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.
A flaw was discovered in a third-party vendor patch to the OpenSSL library which affected random number generator seeding (CVE-2008-0166). This patch has never been used by Red Hat, and this issue does not affect any Fedora, Red Hat, or upstream supplied OpenSSL packages.
Any cryptographic keys or encrypted data generated on a system using a distribution which was affected may be predictable and should be replaced. Affected vendors will be publishing advisories and advice on how to do this.