|
From: Christoph B. <bar...@or...> - 2008-05-13 21:42:26
|
Hi, I've read about the debian SSL bug. http://wiki.debian.org/SSLkeys There they state: It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. Apparently they disabled to many seeds with the patch. Unfortunately origin tracking comes too late. :) Christoph |
|
From: Dirk S. <val...@ds...> - 2008-05-14 07:09:26
|
On Tue, 13 May 2008, Christoph Bartoschek wrote: > I've read about the debian SSL bug. http://wiki.debian.org/SSLkeys > > There they state: > > It is important to understand that this problem was caused by trying to remove > valgrind warnings related to the use of uninitialised memory within the > openssl libraries. > > > Apparently they disabled to many seeds with the patch. Unfortunately origin > tracking comes too late. :) After I read the rants against Debian, I ask myself why not one of the OpenSSL authors actually agreed, that taking uninitialised memory is no good idea (as it is in no way random). They should have replaced that code long ago by better randomness. I really hate these library authors not caring for valgrind and memory checks. So many problems in glib, x-libs and others which make debugging own applications a very hard task. And the result are many memory holes and illegal accesses in all the GUI applications using these libraries (or am I the only one who finds it hard to debug e.g. a Qt/KDE program using valgrind). Reminds me of the Amiga, where program authors used direct ROM calls and other evil things and then blamed the operating system for changing instead seeing problems in their own programming style. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Christoph B. <bar...@or...> - 2008-05-14 07:40:47
|
Am Mittwoch, 14. Mai 2008 schrieb Dirk Stoecker: > After I read the rants against Debian, I ask myself why not one of the > OpenSSL authors actually agreed, that taking uninitialised memory is no > good idea (as it is in no way random). They should have replaced that code > long ago by better randomness. The OpenSSL authors do the right thing: 1. They do not depend on the memory randomness. It is just an additional source to many other real random sources. 2. Uninitialized memory does not help for randomness but it also does not hurt. 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of uninitialized memory. This should pacify valgrind for all people that have to debug their applications. Christoph |
|
From: Julian S. <js...@ac...> - 2008-05-14 07:55:11
|
> 2. Uninitialized memory does not help for randomness but it also does not > hurt. If you say it does not help for randomness, why then use it? > 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of > uninitialized memory. This should pacify valgrind for all people that have > to debug their applications. True, but it has the bad effect that you need to recompile OpenSSL in order to use Memcheck on any applications which use it. This is extra hassle for programmers and packagers. At least with the new --track-origins=yes facility in V 3.4.0 it will be easy to find out which uninitialised value errors are as a result of OpenSSL using uninitialised memory. J |
|
From: Dirk S. <val...@ds...> - 2008-05-14 08:43:54
|
On Wed, 14 May 2008, Christoph Bartoschek wrote: >> After I read the rants against Debian, I ask myself why not one of the >> OpenSSL authors actually agreed, that taking uninitialised memory is no >> good idea (as it is in no way random). They should have replaced that code >> long ago by better randomness. > > The OpenSSL authors do the right thing: No. > 1. They do not depend on the memory randomness. It is just an additional > source to many other real random sources. Fine. > 2. Uninitialized memory does not help for randomness but it also does not > hurt. It does hurt. It produces very hard traceable warnings in user applications. The OpenSSL team also recogniced this or the PURIFY define would not be in the code. But they did not do the right thing: Fix the code to not rely on questionable randomness. > 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of > uninitialized memory. This should pacify valgrind for all people that have to > debug their applications. No it does not. Users want to debug user applications, not the whole system. Recompiling parts of the operating system support libraries is no option. Library code has to follow much higher coding standards than any user application. But only few library developers really handle accordingly. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Erik de C. L. <eri...@me...> - 2008-05-14 08:13:33
|
Christoph Bartoschek wrote: > The OpenSSL authors do the right thing: I disagree. Openssl is a prime example of a library which was poorly designed, a long time ago and has been badly maintained since. Its a pity that this is the most widely used SSL library available under a free license. > 1. They do not depend on the memory randomness. True. > It is just an additional > source to many other real random sources. Randomness of such poor quality that it may as well all be zero bytes. > 2. Uninitialized memory does not help for randomness but it also does not > hurt. True. > 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of > uninitialized memory. This *only* works if you compile openssl yourself, from source. If I link my program against the openssl that comes with my Linux distribution and run it under valgrind I get errors from openssl. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "He who writes the code gets to choose his license, and nobody else gets to complain" -- Linus Torvalds |
|
From: Julian S. <js...@ac...> - 2008-05-14 08:42:35
|
> > It is just an additional > > source to many other real random sources. > > Randomness of such poor quality that it may as well all be zero bytes. It would be interesting to know if the OpenSSL people have any numbers which indicate how much extra entropy you can get this way. I suspect, for different runs of the same program on the same machine, especially with the same input data, it is close to zero. J |
|
From: Bart V. A. <bar...@gm...> - 2008-05-14 08:27:09
|
On Wed, May 14, 2008 at 10:13 AM, Erik de Castro Lopo <eri...@me...> wrote: > Christoph Bartoschek wrote: >> 2. Uninitialized memory does not help for randomness but it also does not >> hurt. > > True. If uninitialized memory does not help for randomness, why was leaving out uninitialized memory as a randomness source considered to be a security hole ? See also http://lwn.net/Articles/281901/. Bart. |
|
From: Tom H. <to...@co...> - 2008-05-14 08:33:23
|
In message <e2e...@ma...>
Bart Van Assche <bar...@gm...> wrote:
> On Wed, May 14, 2008 at 10:13 AM, Erik de Castro Lopo
> <eri...@me...> wrote:
>> Christoph Bartoschek wrote:
>>> 2. Uninitialized memory does not help for randomness but it also does not
>>> hurt.
>>
>> True.
>
> If uninitialized memory does not help for randomness, why was leaving
> out uninitialized memory as a randomness source considered to be a
> security hole ? See also http://lwn.net/Articles/281901/.
It wasn't, but they also took out another (identical) line of code
that was actually adding genuine random (and initialised) data at
the same time.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Erik de C. L. <eri...@me...> - 2008-05-14 09:00:01
|
Bart Van Assche wrote: > If uninitialized memory does not help for randomness, why was leaving > out uninitialized memory as a randomness source considered to be a > security hole ? See also http://lwn.net/Articles/281901/. >From the thread on LWN: # Basically, openssl was feeding uninitialized memory to the random # number generator as seed data, and this was generating warnings in # valgrind and other memory checkers. This was disabled, which # silenced valgrind. Unfortunately, it also served to deplete the # amount of entropy available to the RNG. Of course, the question # that others have raised is awfully interesting: Is there really # that much entropy in uninitialized memory to begin with? It was random-ness, just random-ness with of an extremely low quality. The bug was setting the seed to zero. A better solution would be to generate a truely random seed. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- A sufficiently advanced programming error is indistinguishable from the Windows 95 Operating System. |
|
From: Tom H. <to...@co...> - 2008-05-14 09:08:24
|
In message <200...@me...>
Erik de Castro Lopo <eri...@me...> wrote:
> From the thread on LWN:
>
> # Basically, openssl was feeding uninitialized memory to the random
> # number generator as seed data, and this was generating warnings in
> # valgrind and other memory checkers. This was disabled, which
> # silenced valgrind. Unfortunately, it also served to deplete the
> # amount of entropy available to the RNG. Of course, the question
> # that others have raised is awfully interesting: Is there really
> # that much entropy in uninitialized memory to begin with?
>
> It was random-ness, just random-ness with of an extremely low
> quality. The bug was setting the seed to zero. A better solution
> would be to generate a truely random seed.
That quote is not an accurate description of what happened
though. If you look further down the LWN thread you will
discover that in fact a second call to MD_Update was also
disabled and that one was adding the real random data.
The original commit that caused the problem is http://tinyurl.com/5mmheo
and the fix is http://tinyurl.com/58phtk.
As you can see, the original comments out two calls to MD_Update
and the fix only reverts one of them - the one which is not already
guarded by a PURIFY ifdef because that is the one which is adding
real initialised data to the hash.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Ashley P. <api...@co...> - 2008-05-14 09:48:01
|
On Wed, 2008-05-14 at 10:08 +0100, Tom Hughes wrote: > The original commit that caused the problem is http://tinyurl.com/5mmheo > and the fix is http://tinyurl.com/58phtk. Thank you for posting that, I'd been looking for those. I too had been wondering why they were using stack entropy as it is seems almost pointless. > As you can see, the original comments out two calls to MD_Update > and the fix only reverts one of them - the one which is not already > guarded by a PURIFY ifdef because that is the one which is adding > real initialised data to the hash. I wonder if the ssl developers will merge back the remaining change? Ashley, |
|
From: Steven S. <so...@ca...> - 2008-05-14 09:14:35
|
> > It is just an additional > > source to many other real random sources. > Randomness of such poor quality that it may as well all be zero bytes. Well, maybe. If you're using address space layout randomisation then pointers contain a significant amount of entropy, so if there were any of them left over in the uninitialised buffer you might be able to glean a few bits from that. It's still not high quality entropy, but it should be better than nothing for most users of the library. Admittedly, the dubious seeding predates ASLR, so it was pretty useless when it was written, but on modern kernels it's at least potentially useful. Steven. |
|
From: Julian S. <js...@ac...> - 2008-05-14 09:25:24
|
On Wednesday 14 May 2008 11:14, Steven Smith wrote: > > > It is just an additional > > > source to many other real random sources. > > > > Randomness of such poor quality that it may as well all be zero bytes. > > Well, maybe. If you're using address space layout randomisation then > pointers contain a significant amount of entropy, so if there were any > of them left over in the uninitialised buffer you might be able to > glean a few bits from that. It's still not high quality entropy, but > it should be better than nothing for most users of the library. In that case, just use the address of some function in the library as a source of randomness, since ASLR will result in the library being mapped at different addresses from run to run. That avoids having to hope that there are some useful pointers left hanging around in the buffer. J |
|
From: Dirk S. <val...@ds...> - 2008-05-14 09:15:55
|
On Wed, 14 May 2008, Erik de Castro Lopo wrote: > # Basically, openssl was feeding uninitialized memory to the random > # number generator as seed data, and this was generating warnings in > # valgrind and other memory checkers. This was disabled, which > # silenced valgrind. Unfortunately, it also served to deplete the > # amount of entropy available to the RNG. Of course, the question > # that others have raised is awfully interesting: Is there really > # that much entropy in uninitialized memory to begin with? > > It was random-ness, just random-ness with of an extremely low > quality. The bug was setting the seed to zero. A better solution > would be to generate a truely random seed. Uninitialized memory is no randomness. E.g. On Amiga systems nearly every developer used Mungwall. This tool initialized every piece of memory with 100% predictable bit patterns. No randomness at all. BTW: To come back on-topic: Does valgrind have such an option? MungWall e.g. used patters like 0xBAADCAFE, 0xDEADBEEF, 0xCODEBAAD and so on for different memory types (inside of allocations, before allocations, behind allocations, on stack, ... This usually lead to program failures or unexpected behaviour. Now valgrind does track every unitialized memory, so the above seems not to be necessary, but possibly there are usages? I still wish me MungWall/Enforcer for Linux systems, as these debugged the whole system in real-time and not only one application like valgrind does. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Oliver G. <ol...@gm...> - 2008-05-14 11:40:34
|
On Wed, 14 May 2008 11:15:59 +0200 (CEST) Dirk Stoecker <val...@ds...> wrote: > On Wed, 14 May 2008, Erik de Castro Lopo wrote: > > > # Basically, openssl was feeding uninitialized memory to the random > > # number generator as seed data, and this was generating warnings in > > # valgrind and other memory checkers. This was disabled, which > > # silenced valgrind. Unfortunately, it also served to deplete the > > # amount of entropy available to the RNG. Of course, the question > > # that others have raised is awfully interesting: Is there really > > # that much entropy in uninitialized memory to begin with? > > > > It was random-ness, just random-ness with of an extremely low > > quality. The bug was setting the seed to zero. A better solution > > would be to generate a truely random seed. > > Uninitialized memory is no randomness. E.g. On Amiga systems nearly > every developer used Mungwall. This tool initialized every piece of > memory with 100% predictable bit patterns. No randomness at all. > > BTW: To come back on-topic: Does valgrind have such an option? > MungWall e.g. used patters like 0xBAADCAFE, 0xDEADBEEF, 0xCODEBAAD > and so on for different memory types (inside of allocations, before > allocations, behind allocations, on stack, ... > > This usually lead to program failures or unexpected behaviour. Now > valgrind does track every unitialized memory, so the above seems not > to be necessary, but possibly there are usages? > > I still wish me MungWall/Enforcer for Linux systems, as these > debugged the whole system in real-time and not only one application > like valgrind does. > > Ciao Under Linux + glibc, there's the MALLOC_PERTURB_ env var; if it is set, malloc will return memory that is initialized with the env var's value. I have added "setenv MALLOC_PERTURB_ 187" to my ~/.cshrc (187 = 0xBB is randomly chosen), and if I now see that a pointer has value 0xBBBBBBBB or 0x44444444 in gdb I know the pointer itself has probably not been initialized. There's also MALLOC_CHECK_, but I have only been able to catch double free() calls with that (it didn't find an off-by-one error). Regards, Oliver Gerlich |
|
From: Nicholas N. <nj...@cs...> - 2008-05-14 23:09:35
|
On Wed, 14 May 2008, Dirk Stoecker wrote: > BTW: To come back on-topic: Does valgrind have such an option? > MungWall e.g. used patters like 0xBAADCAFE, 0xDEADBEEF, 0xCODEBAAD and so > on for different memory types (inside of allocations, before allocations, > behind allocations, on stack, ... See the --malloc-fill and --free-fill options for Memcheck. I think Valgrind may also use such patterns internally, to help catch errors within Valgrind itself, but I'm not certain. Nick |
|
From: Paul F. <pa...@fr...> - 2008-05-14 18:09:57
|
Christoph Bartoschek wrote: > Hi, > > I've read about the debian SSL bug. http://wiki.debian.org/SSLkeys > > There they state: > > It is important to understand that this problem was caused by trying to remove > valgrind warnings related to the use of uninitialised memory within the > openssl libraries. > > > Apparently they disabled to many seeds with the patch. Unfortunately origin > tracking comes too late. :) Hi Why doesn't debian SSL supply, or at least users generate, a suppression file? Then you could simply forget about the nastiness of reading uninitialized memory. A+ Paul |
|
From: Nicholas N. <nj...@cs...> - 2008-05-17 12:22:56
|
A good summary: http://blog.rominet.net/2008/05/debianopenssl-debacle.html |
|
From: Julian S. <js...@ac...> - 2008-05-20 20:04:40
|
On Saturday 17 May 2008 13:22:52 Nicholas Nethercote wrote: > A good summary: > > http://blog.rominet.net/2008/05/debianopenssl-debacle.html Sheesh! And for a moment there I thought it was a serious link :-) J > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |