Bug 65753 (CVE-2005-0106)

<!-- SBZ_reproduce  -->
-

Created attachment 28422 [details]
ssleay.diff

Issue is not public, please keep inside suse. 

Please assign to the maintainer of the package, I just do core perl.

From: Jacques Vidrine <nectar@FreeBSD.org> 
To: Martin Schulze <joey@infodrom.org> 
Cc: Free Software Distribution Vendors <vendor-sec@lst.de> 
Subject: Re: [vendor-sec] CAN-2005-0106: Insecure entropy source in Net::SSLeay 
User-Agent: Mutt/1.5.6i 
Errors-To: vendor-sec-admin@lst.de 
Date: Wed, 23 Feb 2005 09:43:34 -0600 
 
On 2/10/05 12:00 PM, Martin Schulze wrote: 
>Javier Fernández-Sanguino Peña wrote: 
> 
>While doing a source code audit for /tmp usage in Debian packages which 
>might pose a security issue I've found this code snippet in Net::SSleay 
>(libnet-ssleay-perl in Debian which ships both versions 1.08-1 and 1.25-1) 
>which I'm slightly worried about: 
> 
>   1852 sub randomize (;$$) { 
>(...) 
>   1856     $egd_path = $ENV{'EGD_PATH'} if $ENV{'EGD_PATH'}; 
>   1857     $egd_path = '/tmp/entropy'   unless $egd_path; 
> 
>Now, besides the fact that Debian does not provide EGD [1], what would be 
>the consequences to applications ussing this perl module if, at the same 
>time, a rogue local user created a '/tmp/entropy' socket that did not 
>provide proper entropy? OpenSSL (as far as I have seen, in 
>crypto/rand/rand_egd.c) will not do any checks on the file provided as a 
>path to RAND_query_egd_bytes() (I'm not sure if it should do any, however) 
 
Hi! 
 
I don't think that there is much consequence, as long as /tmp/entropy 
was not the only source of entropy.  Linux has /dev/urandom, right? 
/tmp/entropy is just one source of entropy... 
 
   1865     RAND_load_file($rn_seed_file, -s _) if $rnsf; 
   1866     RAND_seed($seed) if $seed; 
   1867     RAND_seed($ENV{RND_SEED}) if $ENV{RND_SEED}; 
   1868     RAND_egd($egd_path) if -S $egd_path; 
   1869     RAND_load_file($Net::SSLeay::random_device, 
        $Net::SSLeay::how_random/8) 
   1870         if -r $Net::SSLeay::random_device; 
 
In addition to the explicit RAND_load_file of /dev/urandom on line 1869, 
I believe that OpenSSL will implicitly mix in more data from /dev/urandom. 
 
I suspect that in this case, where suitable entropy is mixed in, 
additionally mixing in an attacker's data will not decrease the 
quality of the PRNG output.  If so, then I think that CAN-2005-0106 
should be cancelled.  I'll check with someone who knows better... 
 
Cheers, 
-- 
Jacques A Vidrine / NTT/Verio 
nectar@celabo.org / jvidrine@verio.net / nectar@FreeBSD.org 
 
 

You can use this for a DOS attack against NET::SSLeay, so it should not be 
cancelled... 

You think about a local user creates the socket but does not send data through 
it? 
 
At least the EGD socket and /dev/urandom (which depends on the kernels entropy 
pools which can be emptied by local users) can fall under control by a local 
attacker. How much entropy will be left then? 

yes. /dev/urandom doesn't block, though... I don't know about egd. 

So, no local DoS? 

That's not what I said. I said it's an local DoS because Net::SSLeay will 
wait forever on the socket. 

But you said you do not know if it blocks on the edg socket. 
"I don't know about egd" 

No, you misunderstood. Net::SSLeay will always block. I don't know if draining 
the edg server will also be a DOS. Draining /dev/urandim will not work, 
obviously, 

ah ok. :)


an interesting topic is still left: will the entropy left fulfil the
requirements? :) 

I don't know, but there's a comment in Net::SSLeay: 
 
# Edit to your taste. Using /dev/random would be more secure, but may 
# block if randomness is not available, thus the default is 
# /dev/urandom. $how_random determines how many bits of randomness to take 
# from the device. You should take enough (read SSLeay/doc/rand), but 
# beware that randomness is limited resource so you should not waste 
# it either or you may end up with randomness depletion (situation where 
# /dev/random would block and /dev/urandom starts to return predictable 
# numbers). 

Fix in stable is enough.... 

Is aplying the patch enough?

yes, it is. 

fixed

CVE-2005-0106: CVSS v2 Base Score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)