[ROS] The perils of security tools
ben at links.org
Tue May 13 18:27:52 EDT 2008
Steven M. Bellovin wrote:
> On Tue, 13 May 2008 23:00:57 +0100
> Ben Laurie <ben at links.org> wrote:
>> 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.
> So why are are the keys so guessable? Or did they delete other 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."
"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