Bugzilla – Bug 866286
VUL-0: CVE-2014-0016: stunnel: PRNG reseed vulnerability
Last modified: 2018-02-15 15:36:28 UTC
bugbot adjusting priority
is public now. Date: Wed, 05 Mar 2014 11:11:07 +0530 From: Huzaifa Sidhpurwala <huzaifas@redhat.com> Subject: [oss-security] libssh and stunnel PRNG flaws Hi All, Aris Adamantiadis reported the following to us: I have found a vulnerability in stunnel (fork mode) and libssh server (if implemented with fork) that is similar to problems found in postgresql [1]. When accepting a new connection, the server forks and the child process handles the request. The RAND_bytes() function of openssl doesn't reset its state after the fork, but simply adds the current process id (getpid) to the PRNG state, which is not guaranteed to be unique. stunnel uses libssl, which also seeds the PRNG with the output of time(NULL), which means that vulnerability has to be exploited under a second. I have exploit code that can reproduce the issue on OpenBSD 5.4 (thanks to random PIDs) but I think it may be exploitable on other unix systems as well. The following CVEs have been assigned: CVE-2014-0016 stunnel PRNG vulnerability CVE-2014-0017 libssh PRNG vulnerability Mitigations implemented into openssl-0.9.8j (2009) makes the vulnerability not exploitable in stock openssl. The signing code for ECDSA and DSA explicitly seeds the pool with the digest to sign. References: libssh: https://bugzilla.redhat.com/show_bug.cgi?id=1072191 http://www.libssh.org/2014/03/04/libssh-0-6-3-security-release/ http://git.libssh.org/projects/libssh.git/commit/?id=e99246246b4061f7e71463f8806b9dcad65affa0 stunnel: https://bugzilla.redhat.com/show_bug.cgi?id=1072180 There is no upstream patch yet
Created attachment 581220 [details] relevant patch between stunnel 5.00b1 and 5.00 ga this is the diff I think
Created attachment 581369 [details] Fix for CVE-2014-0016 Backported fix for CVE-2014-0016.
The SWAMPID for this issue is 56563. This issue was rated as moderate. Please submit fixed packages until 2014-03-21. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Affected packages: SLE-11-SP3: stunnel SLE-10-SP3-TERADATA: stunnel SLE-11-SP2: stunnel
The SWAMPID for this issue is 56564. This issue was rated as moderate. Please submit fixed packages until 2014-03-21. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Hm, I don't think we need to update SLE10: --with-threads=pthreads (and that's the default if nothing is given) in other words, stunnel on SLE10 and SLE11 is using pthreads and does not fork. Verified that on a test system here with a debug patch. Code is not being executed as expected. We are always using pthread threading model, not fork. So #ifdef USE_FORK does not trigger, and the CVE does not apply. The patch effort would only help customers recompiling stunnel with different options. Not sure we should go through the update effort for that. Marcus, what do you say/think? For SLES9 I need to find the build logs to be sure.
Ok, SLE9 uses pthread, too.
resolved