[ROS] The perils of security tools
ben at links.org
Tue May 13 18:00:57 EDT 2008
Steven M. Bellovin wrote:
> 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 by removing any
>> possibility of adding any entropy to OpenSSL?s pool of randomness.
>> 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.
>>  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
"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 majordomo at metzdowd.com
More information about the cryptography