Bugzilla – Bug 65753
VUL-0: CVE-2005-0106: perl: Net::SSLeay uses insecure path for entropy socket
Last modified: 2021-10-27 15:57:09 UTC
Hi, the debian folks found the following. rom: Martin Schulze <joey@infodrom.org> To: Free Software Distribution Vendors <vendor-sec@lst.de> User-Agent: Mutt/1.5.6+20040907i Subject: [vendor-sec] CAN-2005-0106: Insecure entropy source in Net::SSLeay Errors-To: vendor-sec-admin@lst.de Date: Thu, 10 Feb 2005 19:00:03 +0100 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) I don't think that /tmp/entropy should be used if EGD_PATH is undefined since it seems like a possible venue of attack (similarly. I'm not sure if it would be possible or if it would have any reasonable impact but IMHO line 1857 should be removed from the code. Shouldn't it? If you all agree with the above, would be the attached patch a proper fix? Sampo Kellomaki <sampo@iki.fi> (upstream) added: Well, perhaps, but you need to understand that I aim supporting platforms other than Linux. Solaris 2.6 for example does not have /dev/urandom (which in itself is a security problem as well when you have entropy depletion, but even Linux vendors seem to be happy to ignore that) and therefore you are expected to install EGD or prngd (both of which can even be installed on Linux, BTW). Now the mechanics of that statement may in particular wrong and the right solution probably would be to add EGD as a dependency check in perl Makefile.pl. However, since I have limited resources to answer questions or develop ultra sophisticated configuration scripts that still need to be debugged etc., thus I just kludged it that way to silence the barrage of newbie email. [..] If you patch it, please make sure Solaris 2.6 continues to be supported and the case where EGD or prngd is missing is fixed such that I do not get newbie mail. [..] Thank you. Since it is a vulnearability and since no fix is forthcoming in short time period it should be disclosed immediately so that the affected know and can make their judgements. Hence, we're going to update the package next week with the attached patch. Regards, Joey -- GNU GPL: "The source will be with you... always."
<!-- 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)