[ROS] The perils of security tools

[Steven M. Bellovin]

On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie <ben at links.org> wrote:

> 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.
> 
....
> 
> [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.
> 
Ben: I haven't looked at the actual code in question -- are you saying
that the *only* way to add more entropy is via this pool of
uninitialized memory?  If so, is there any support in the relevant
standards that dictate that this memory MUST NOT be cleared?  I was
thinking of things like SELinux, which may (or may not) clear memory
areas before handing it to an application.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com