Re: [ROS] The perils of security tools

[Ben Laurie]

Steven M. Bellovin wrote:

On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie <[EMAIL PROTECTED]> 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?

No. That would be fantastically stupid.

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

--
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]