The PRNG is initialized when you initialize OpenSSL, and I'll concede,
someone COULD use fgets() before that, but it's a really improbable
scenario and in any case - the PRNG being vulnerable is the least of your
worries then ....
Sure you can stuff known data into there - if you are running in the same
process address space (just read the keys), if you are in the kernel (just
read the keys), if you have the same UID (or root UID) - (just read the
keys), you can even do it via fgets(), no argument, your example is valid -
but can you do it before OpenSSL has been initialized ? - well, maybe some
badly written code COULD do that, but it doesn't matter, if you control the
stack to that extent you can also engineer a buffer overrun, insert your
own code and simply read the generated keys - which is much simpler than
cracking the PRNG.
As MANY others pointed out - simply putting known data in there doesn't
decrease the entropy - worst case it's exactly what it was before. (The
hash function is irreversible in this case - effectively it's compressing
the data). So best case, you do have data there which is machine or
instance dependent and the PNG is even less predictable that it was, worst
case it's as strong as it was before you added the known data.
I'm not claiming this is "best practice", but it's not intrinsically bad
either.
Peter
From: Nils Gösche <[EMAIL PROTECTED]>
To: openssl-dev@openssl.org
Date: 05/21/2008 07:57 PM
Subject: Re: valgrind and openssl
Peter Waltenberg wrote:
> Think back to what tripped this whole discussion.
>
> valgrind isn't complaining because the data has been pre-filled, it's
> complaining because it's never been touched.
> i.e if it were attacker providable "buffer contents" then this whole
> discussion wouldn't have happened.
>
> If the "attacker" can pre-seed uninitialized data in the process, then
they
> can read generated keys directly - and that's far easier than by trying
to
> second guess the RNG.
>
Consider this little piece of code:
#include <stdio.h>
#include <stdlib.h>
void f(void)
{
char buf[80];
printf("Please enter a line: ");
fflush(stdout);
fgets(buf, sizeof buf, stdin);
}
void g(void)
{
char buf[80];
/* Use uninitialized buffer content... */
printf("Buf contains %s\n", buf);
}
int main(void)
{
f();
g();
return 0;
}
On my system, this yields:
[EMAIL PROTECTED]:~/src$ gcc buf.c
[EMAIL PROTECTED]:~/src$ ./a.out
Please enter a line: blark foo
Buf contains blark foo
[EMAIL PROTECTED]:~/src$
:-) The reason this works is that when fgets writes into the stack
memory, this memory is reused in the function g() without being
reinitialized.
So, it is sometimes possible indeed that an attacker will be able to
provide (some of) the content of uninitialized memory, if he gets to
interact with the program in some way.
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
