|
From: Steve G <lin...@ya...> - 2003-05-23 14:22:35
Attachments:
ssltest.c
|
Hello, I've been doing some testing of daemon's using valgrind. I've run across a problem with valgrind and have created a simple test program. I've tried several different versions of valgrind including cvs. I've attached a program that can be compiled as: gcc -o ssltest ssltest.c -lcrypto The valgrind line I use is: valgrind --num-callers=8 --logfile-fd=19 --leak-check=yes --leak-resolution=high ssltest 19>out The problem I see is: ==7796== Use of uninitialised value of size 4 ==7796== at 0x40267B6B: RC4_set_key (rc4_skey.c:111) ==7796== by 0x80485FC: arc4random_stir (in /home/steve/ssl_test/ssltest) ==7796== by 0x804862D: main (in /home/steve/ssl_test/ssltest) ==7796== by 0x40330A46: __libc_start_main (in /lib/libc-2.3.2.so) ==7796== by 0x80484CC: ??? (start.S:81) If you uncomment the dump_buffer lines & re-run, you can see that all the bytes are changed/initialized by the call to RAND_bytes. I see this kind of problem in sshd, stunnel, or apache when I do testing. Since these are security related programs, I am curious about what is happening or correcting the problem. TIA, Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Crispin F. <cr...@th...> - 2003-05-23 15:37:00
|
On Fri, 2003-05-23 at 15:22, Steve G wrote: > Hello, > > I've been doing some testing of daemon's using valgrind. > I've run across a problem with valgrind and have created a > simple test program. I've tried several different versions > of valgrind including cvs. > > I've attached a program that can be compiled as: > > gcc -o ssltest ssltest.c -lcrypto This is a known problem in openssl. It uses uninitialzed data to generate random numbers. The dodgy code is in md_rand.c (search for PURIFY). See: http://www.mail-archive.com/ope...@op.../msg15497.html (just for reference, your test program can be shortened as follows (making use of the very useful VALGRIND_* macros) #include <openssl/rand.h> #include <openssl/err.h> #include <valgrind/memcheck.h> int main(void) { unsigned char rand_buf[20]; if (!RAND_bytes(rand_buf, sizeof(rand_buf))) printf("Couldn't obtain random bytes" ); VALGRIND_CHECK_READABLE( rand_buf, sizeof( rand_buf ) ); return 0; } Crispin |
|
From: Steve G <lin...@ya...> - 2003-05-23 16:57:39
|
>This is a known problem in openssl. It uses uninitialzed
>data to generate random numbers.
Right, but is that a transferable property? I think this is
something different. The call chain I posted is the
RC4_key_set call.
Before I sent the original e-mail, I traced through all the
ssl calls with ddd. The code in ssleay_rand_bytes adds a
number to each byte in the array. Valgrind complains about
this since the bytes are being used unintialized...however,
the buffer has been written to. Every single byte has
changed.
I guess this illustrates the problem:
int main(void)
{
char buf1[20], buf2[20];
memcpy(buf1, buf2, 20);
puts(buf1);
}
every single byte in buf1 has been written to. Is buf1
considered uninitialized in the call to puts? Shouldn't the
memcpy actually be the error? Everything I see output from
the simplified program above
-Steve Grubb
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
|
|
From: Crispin F. <cr...@th...> - 2003-05-23 17:18:30
|
On Fri, 2003-05-23 at 17:57, Steve G wrote: > >This is a known problem in openssl. It uses uninitialzed > >data to generate random numbers. > > Right, but is that a transferable property? I think this is > something different. The call chain I posted is the > RC4_key_set call. Valgrind keeps track of which bytes (bits?) of memory are initialised and complains when you use them (system call, conditional jump etc). I suggest you read the stuff about the memcheck skin at: http://devel-home.kde.org/~sewardj/docs-1.9.5/mc_main.html#errormsgs which explains when the error messages are printed (hint, you can copy bogus data around all you want) As an aside, you can fix the problem by adding a call to VALGRIND_MAKE_READABLE( ptr, len ) after the call to RAND_Bytes and your errors will go away. Crispin |
|
From: Nicholas N. <nj...@ca...> - 2003-05-23 17:21:44
|
On Fri, 23 May 2003, Steve G wrote:
> I guess this illustrates the problem:
>
> int main(void)
> {
> char buf1[20], buf2[20];
>
>
> memcpy(buf1, buf2, 20);
>
> puts(buf1);
>
>
> }
>
> every single byte in buf1 has been written to. Is buf1
> considered uninitialized in the call to puts? Shouldn't the
> memcpy actually be the error? Everything I see output from
> the simplified program above
The V (validity) bits are used to detect if any of the following
operations depend on uninitialised values:
- conditional tests and moves,
- system calls
- memory address computations.
The V bits are not checked simply when a value is read, because partially
defined words are often copied around, due to the common practice of
padding structures to ensure fields are word-aligned. It doesn't even
complain if you add two uninitialised integers, because that doesn't
affect the behaviour of the program (unless the result is used in one
of the above three operations, then it complains).
N
|