[ROS] The perils of security tools
Ben Laurie
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[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 majordomo at metzdowd.com
More information about the cryptography
mailing list