TCLP 2008-05-18 News (Comment Line 240-949-2638)

This is news cast 141.

I will be at Balticon 42 next weekend, so no news show that Sunday. I was going to skip the feature cast, too, to make more time to prepare, but I lucked into a last minute interview which I will share on Wednesday. More details when that show goes live.

Security alerts this week are the Debian GNU/Linux project fixes a critical crypto bug and PayPal is proven vulnerable despite using an enhancement to plain SSL security.

In this week’s news, researchers look at providing social interactions for remote workers though I worry this may exacerbate some other workplace trends, the USAF contemplates building a botnet, some of the risks of the cutover to digital TV, and NBC briefly activates thier broadcast flag although the EFF defended device makers’ right to ignore the flag.

Following up this week, a couple of cases go against the RIAA in particular Judge Davis in the Thomas case thinks he made an error.

Download the show directly. Grab the detailed show notes with time offsets and additional links either as PDF or OPML.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

3 Replies to “TCLP 2008-05-18 News (Comment Line 240-949-2638)”

  1. Hey, I’ll be at Balticon as well. Perhaps we’ll run into each other. They don’t seem to have a schedule up, so the only thing I can say I’ll attend with any probability is the medieval dance, 2-4 pm Saturday.

  2. The OpenSSL bug is much much larger than you mentioned. It also can directly effect anyone who runs Linux or uses a Linux server.

    Basically the Debian OpenSSL maintainer found a problem with OpenSSL and Valgrind. Valgrind was complaining about the use of uninitialized memory. The maintainer then emailed the openssl-dev list asking if removing the offending lines would be a problem. Two people replied that it seemed fine, including one of the OpenSSL developers. So the Debian maintainer made a patch removing those lines. One of which was fine to remove because it added the entropy of uninitialized memory to the pool for the PRNG. However a second, identical line added the entropy of /dev/urandom. Removing this second line is the problem. This left only the entropy of the PID as the seed for the PRNG. (In case you are curious, adding the uninitialized memory to the entropy pool is not a problem even if it were a constant value and could only help). Linux only has 2^15 PIDs, which lead to the PRNG only able to create 2^15 keys. Additionally since Debian assigns PIDs sequentially, the keys generated are likely clustered around lower PIDs making things even worse.

    The fallout from the bug is interesting to me. When it was found, Debian issued a security advisory, patch, etc… (which includes Ubuntu since it is Debian derived). A main OpenSSL team member immediately placed all the blame on the Debian maintainer for not properly understanding the problem prior to patching (see the posts at This seems disingenuous to me because the Debian maintainer did attempt to contact the OpenSSL developers (though there was an obvious communication breakdown here). In my opinion the OpenSSL team deserves a fair amount of blame for making it so hard to be contacted, in addition to the obvious blame on the Debian maintainer (what annoys me though is the OpenSSL guys seem to keep moving the goal post, ie “Oh the mailing list listed on and in the README as the contact point for us is wrong, the Debian guy should have contacted this no-where published address instead”, and “Oh the patch is clearly wrong because we have an FAQ about not making such patches (without any substantiation that the FAQ existed at the time the patch was proposed”, and “Sure we said the patch was ok, but that is only because the Debian guy’s email wasn’t clear that he intended to put this into Debian, ’cause if he had known we would have laughed at him”. See the comments to find posts along those lines).

    Anyway this is extremely serious because any key that was generated on a Debian/Debian derived machine in the past two years is likely compromised. This includes things like email keys, ssh host keys, SSL certificates, etc… It affects any Linux user because they could be depending on a server that has a bad key. Any previously captured SSH/SSL transmissions captured with such a key can easily be decrypted now. Even if you are running a non-Debian derived machine it could affect you because you could have a user with a compromised key. An example of what could go wrong is at

    If you want more clarification on any of this, feel free to email me and I’ll be glad to explain to the best of my ability. (I have my real email in the “Mail (will not be published) (required)” box of this post).

    Also, just to be clear on my biases, I’ve used Debian/Ubuntu for around 4 years, but I’m not officially affiliated with either.

Leave a Reply

Your email address will not be published. Required fields are marked *