A security issue in stunnel has been announced today (March 5): http://openwall.com/lists/oss-security/2014/03/05/1 A proposed patch is attached to the RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1072180 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Keywords: (none) => TriagedCC: (none) => dan, guillomovitch, mageia, mageia
Debian apparently did find an upstream patch for this and is backporting it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740802 But they have mentioned that they are not actually affected by the issue, as has RedHat on the bug I linked before, because they both configure the build with "--with-threads=pthread" which disables the codepath where this issue resides. Unfortunately, we configure ours "--with-threads=fork" so we ARE affected. Other than patching, we could just change the thread model our build uses, to fix this.
It is also fixed upstream in 5.00, released yesterday (March 6): http://www.stunnel.org/pipermail/stunnel-announce/2014-March/000074.html
I just updated cauldron package to 5.00.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Thanks. We still have Mageia 3 and Mageia 4 to take care of.
Status: RESOLVED => REOPENEDVersion: Cauldron => 4Resolution: FIXED => (none)Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
I didn't noticed, sorry. I just submitted stunnel-4.55-1.1.mga3 and stunnel-4.56-3.1.mga4. Suggested advisory (shamelessly stolen from Redhat) --------------------------------------------------- A flaw was found in the way stunnel, a socket wrapper which can provide SSL support to ordinary applications, performed (re)initialization of PRNG after fork. 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 seeds the PRNG with the output of time(NULL). The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key. New package releases stunnel-4.55-1.1.mga3 and stunnel-4.56-3.1.mga4 fix this issue by using threads instead of new process to handle connections.
Thanks Guillaume! Advisory: ======================== Updated stunnel package fixes security vulnerability: A flaw was found in the way stunnel, a socket wrapper which can provide SSL support to ordinary applications, performed (re)initialization of PRNG after fork. 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 seeds the PRNG with the output of time(NULL). The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key (CVE-2014-0016). The updated packages fix this issue by using threads instead of new processes to handle connections. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0016 https://bugzilla.redhat.com/show_bug.cgi?id=1072180 ======================== Updated packages in core/updates_testing: ======================== stunnel-4.55-1.1.mga3 stunnel-4.56-3.1.mga4 from SRPMS: stunnel-4.55-1.1.mga3.src.rpm stunnel-4.56-3.1.mga4.src.rpm
Assignee: bugsquad => qa-bugs
Advisory added to svn. No POC, so just testing that it works. Testing complete on Mageia 4 x86_64, where I use stunnel with leafnode.
CC: (none) => davidwhodginsWhiteboard: MGA3TOO => MGA3TOO advisory MGA4-64-OK
Testing mga4 32 tl;dr; - built without fips support but not disabled in conf and doesn't create/chown the chroot directory (/run/stunnel) where it places the pid file. Additionally /run is now tmpfs so it would be lost after a reboot. When debugged/created/configured it does work though. Fails initially with.. # stunnel stunnel 4.56 on i586-mageia-linux-gnu platform Compiled/running with OpenSSL 1.0.1e 11 Feb 2013 Threading:FORK Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP Reading configuration from file /etc/stunnel/stunnel.conf FIPS_mode_set: F06D065: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported Line 61: "[pop3s]": Failed to initialize SSL str_stats: 7 block(s), 126 data byte(s), 406 control byte(s) Added a line somewhere in the top half of /etc/stunnel/stunnel.conf to prevent it using fips. fips = no Then at the bottom of the conf file uncommented the https section and changed the 'accept' port it listens on to 4443 from 443, just so it's non standard. It then fails with.. # stunnel ...etc chroot: No such file or directory (2) ...etc # grep ^chroot /etc/stunnel/stunnel.conf chroot = /run/stunnel The directory doesn't exist in /run though. Looking back at old updates this was apparently fixed in bug 4223 for mga1 and 2 but I guess it wasn't done in Cauldron. /run is now tmpfs so a directory created there would be lost on reboot. Manually creating it anyway.. # mkdir /run/stunnel # chown nobody:nogroup /run/stunnel # ll -d /run/stunnel/ drwxr-xr-x 2 nobody nogroup 40 Mar 24 10:55 /run/stunnel// # stunnel # ps aux | grep stunnel | grep -v grep nobody 7020 0.0 0.0 25856 820 ? Ss 10:56 0:00 stunnel # ll /run/stunnel total 4 -rw-r--r-- 1 nobody nogroup 5 Mar 24 10:56 stunnel.pid Check it's listening.. # netstat -pant | grep :4443 tcp 0 0 0.0.0.0:4443 0.0.0.0:* LISTEN 7020/stunnel Browsed to https://127.0.0.1:4443 and accepted the certificate warnings and saw the 'It Works!' message. Killed it with killall stunnel
Testing mga3 32 This doesn't attempt to use fips so is ok in that regard. The rest is the same as mga4.
(In reply to claire robinson from comment #8) > The directory doesn't exist in /run though. Looking back at old updates this > was apparently fixed in bug 4223 for mga1 and 2 but I guess it wasn't done > in Cauldron. /run is now tmpfs so a directory created there would be lost on > reboot. Actually it's the reverse, there were no changes made in Mageia 2 that weren't made in Cauldron, but there was an additional change made only in Cauldron: http://svnweb.mageia.org/packages/cauldron/stunnel/current/SPECS/stunnel.spec?r1=288889&r2=295571 where it was moved to /run and given a tmpfiles config, and BTW since it has that, the directory will not be *lost* on reboot, it in fact will be *created* at that time. What's missing is the needed macro call in %post so that it also creates the directory at package install time. %post should start with this: %_tmpfilescreate %{name} As far as the fips thing, there were no packaging changes regarding that, so I don't know what to tell you.
I'm guessing it's something in newer openssl.. # stunnel stunnel 4.56 on i586-mageia-linux-gnu platform Compiled/running with OpenSSL 1.0.1e 11 Feb 2013 Threading:FORK Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP ^^^^ mga3 doesn't have this Seems easily fixed with 'fips = no' in the conf though
David do you plan to add this or shall I create a bug for next time?
(In reply to claire robinson from comment #12) > David do you plan to add this or shall I create a bug for next time? I just added the tmpfilescreate thing. I was hoping one of the other packagers would comment about the fips thing, I guess you can create a bug for that. Packages are now: stunnel-4.55-1.2.mga3 stunnel-4.56-3.2.mga4 from SRPMS: stunnel-4.55-1.2.mga3.src.rpm stunnel-4.56-3.2.mga4.src.rpm
Thanks David. Testing complete mga3 32. I'll test the others shortly
Whiteboard: MGA3TOO advisory MGA4-64-OK => MGA3TOO advisory mga3-32-ok MGA4-64-OK
Testing complete mga3 64, mga4 32 & mga4 64. Bug 13124 created for the FIPS issue in mga4
Whiteboard: MGA3TOO advisory mga3-32-ok MGA4-64-OK => MGA3TOO advisory mga3-32-ok mga3-64-ok mga4-32-ok MGA4-64-OK
Advisory updated. Validating. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
http://advisories.mageia.org/MGASA-2014-0144.html
Status: REOPENED => RESOLVEDCC: (none) => pterjanResolution: (none) => FIXED
A reference to Bug 13124 ended up in the advisory by mistake. Can someone remove it?
URL: (none) => http://lwn.net/Vulnerabilities/592681/
Done (and fixed 12980 which was preventing from updating the site)
I added the ref to match the text, it wasn't accidental.
It shouldn't be in the text either. It's not in the advisory I posted and it wasn't fixed with this update.
Yep. That's why I added it.
That doesn't make sense. Advisories are for documenting what was fixed, and anything else one might need to know about the update, not for unfixed known issues that aren't regressions and that current users would already know about or not be affected by