home | list info | list archive | date index | thread index

[OCLUG-Tech] Debian Weak Key Vulnerability [fwd: The perils of security tools]

  • Subject: [OCLUG-Tech] Debian Weak Key Vulnerability [fwd: The perils of security tools]
  • From: Richard Guy Briggs <rgb [ at ] tricolour [ dot ] net>
  • Date: Tue, 13 May 2008 10:23:25 -0400
----- Forwarded message from Ben Laurie <ben [ at ] links [ dot ] org> -----
From: Ben Laurie <ben [ at ] links [ dot ] org>
To: Cryptography <cryptography [ at ] metzdowd [ dot ] com>
Subject: The perils of security tools

[Moderator's note: A quick reminder: please use ASCII except if you
need Unicode to spell your name right. Microsoft's proprietary quote
marks are not a standard and don't look right on non-Microsoft
displays. I edited them out of this by hand. --Perry]

Debian have a stunning example of how blindly fixing "problems" pointed  
out by security tools can be disastrous.

I've blogged about it here: http://www.links.org/?p=327

Vendors Are Bad For Security

I've ranted about this at length before, I'm sure - even in print, in  
O'Reily's Open Sources 2. But now Debian have proved me right (again)  
beyond my wildest expectations. Two years ago, they "fixed" a "problem" in 
OpenSSL reported by valgrind[1] by removing any possibility of adding any 
entropy to OpenSSL's pool of randomness[2].

The result of this is that for the last two years (from Debian's "Edgy"  
release until now), anyone doing pretty much any crypto on Debian (and  
hence Ubuntu) has been using easily guessable keys. This includes SSH  
keys, SSL keys and OpenVPN keys.

What can we learn from this? Firstly, vendors should not be fixing  
problems (or, really, anything) in open source packages by patching them  
locally - they should contribute their patches upstream to the package  
maintainers. Had Debian done this in this case, we (the OpenSSL Team)  
would have fallen about laughing, and once we had got our breath back,  
told them what a terrible idea this was. But no, it seems that every  
vendor wants to "add value" by getting in between the user of the software 
and its author.

Secondly, if you are going to fix bugs, then you should install this maxim 
of mine firmly in your head: never fix a bug you don't understand. I'm not 
sure I've ever put that in writing before, but anyone who's worked with me 
will have heard me say it multiple times.

Incidentally, while I am talking about vendors who are bad for security,  
it saddens me to have to report that FreeBSD, my favourite open source  
operating system, are also guilty. Not only do they have local patches in 
their ports system that should clearly be sent upstream, but they also 
install packages without running the self-tests. This has bitten me twice 
by installing broken crypto, most recently in the py-openssl package.

[1] Valgrind is a wonderful tool, I recommend it highly.

[2] Valgrind tracks the use of uninitialised memory. Usually it is bad to 
have any kind of dependency on uninitialised memory, but OpenSSL happens to 
include a rare case when its OK, or even a good idea: its randomness pool. 
Adding uninitialised memory to it can do no harm and might do some good, 
which is why we do it. It does cause irritating errors from some kinds of 
debugging tools, though, including valgrind and Purify. For that reason, we 
do have a flag (PURIFY) that removes the offending code. However, the 
Debian maintainers, instead of tracking down the source of the 
uninitialised memory instead chose to remove any possibility of adding 
memory to the pool at all. Clearly they had not understood the bug before 
fixing it.

P.S. I'd link to the offending patch in Debian's source repository. If I  
could find a source repository. But I can't.

http://www.apache-ssl.org/ben.html           http://www.links.org/
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo [ at ] metzdowd [ dot ] com
----- End forwarded message -----

	slainte mhath, RGB

Richard Guy Briggs               --  ~\    -- ~\            <hpv.tricolour.net>
<www.TriColour.net>                --  \___   o \@       @       Ride yer bike!
Ottawa, ON, CANADA                  --  Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________