Bug 12943 - stunnel new security issue CVE-2014-0016
Summary: stunnel new security issue CVE-2014-0016
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/592681/
Whiteboard: MGA3TOO advisory mga3-32-ok mga3-64-o...
Keywords: Triaged, validated_update
Depends on:
Blocks:
 
Reported: 2014-03-05 13:46 CET by David Walser
Modified: 2014-04-01 22:35 CEST (History)
7 users (show)

See Also:
Source RPM: stunnel-4.56-3.mga4.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-03-05 13:46:10 CET
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:
David Walser 2014-03-05 13:46:17 CET

Whiteboard: (none) => MGA4TOO, MGA3TOO

Manuel Hiebel 2014-03-05 16:44:48 CET

Keywords: (none) => Triaged
CC: (none) => dan, guillomovitch, mageia, mageia

Comment 1 David Walser 2014-03-07 15:05:42 CET
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.
Comment 2 David Walser 2014-03-07 15:09:06 CET
It is also fixed upstream in 5.00, released yesterday (March 6):
http://www.stunnel.org/pipermail/stunnel-announce/2014-March/000074.html
Comment 3 Guillaume Rousse 2014-03-19 20:24:51 CET
I just updated cauldron package to 5.00.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 4 David Walser 2014-03-19 20:26:38 CET
Thanks.  We still have Mageia 3 and Mageia 4 to take care of.

Status: RESOLVED => REOPENED
Version: Cauldron => 4
Resolution: FIXED => (none)
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO

Comment 5 Guillaume Rousse 2014-03-19 20:55:01 CET
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.
Comment 6 David Walser 2014-03-20 13:05:07 CET
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

Comment 7 Dave Hodgins 2014-03-20 20:43:13 CET
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) => davidwhodgins
Whiteboard: MGA3TOO => MGA3TOO advisory MGA4-64-OK

Comment 8 claire robinson 2014-03-24 13:03:08 CET
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
Comment 9 claire robinson 2014-03-24 13:05:02 CET
Testing mga3 32

This doesn't attempt to use fips so is ok in that regard. 
The rest is the same as mga4.
Comment 10 David Walser 2014-03-24 21:38:25 CET
(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.
Comment 11 claire robinson 2014-03-24 22:14:41 CET
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
Comment 12 claire robinson 2014-03-29 13:41:58 CET
David do you plan to add this or shall I create a bug for next time?
Comment 13 David Walser 2014-03-29 19:18:36 CET
(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
Comment 14 claire robinson 2014-03-31 12:49:52 CEST
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

Comment 15 claire robinson 2014-03-31 13:07:27 CEST
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

Comment 16 claire robinson 2014-03-31 13:22:45 CEST
Advisory updated. Validating.

Could sysadmin please push to 3 & 4 updates

Thanks

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 17 Pascal Terjan 2014-03-31 21:41:54 CEST
http://advisories.mageia.org/MGASA-2014-0144.html

Status: REOPENED => RESOLVED
CC: (none) => pterjan
Resolution: (none) => FIXED

Comment 18 David Walser 2014-04-01 19:09:42 CEST
A reference to Bug 13124 ended up in the advisory by mistake.  Can someone remove it?

URL: (none) => http://lwn.net/Vulnerabilities/592681/

Comment 19 Pascal Terjan 2014-04-01 19:30:46 CEST
Done (and fixed 12980 which was preventing from updating the site)
Comment 20 claire robinson 2014-04-01 20:07:52 CEST
I added the ref to match the text, it wasn't accidental.
Comment 21 David Walser 2014-04-01 21:33:11 CEST
It shouldn't be in the text either.  It's not in the advisory I posted and it wasn't fixed with this update.
Comment 22 claire robinson 2014-04-01 21:59:18 CEST
Yep. That's why I added it.
Comment 23 David Walser 2014-04-01 22:35:07 CEST
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

Note You need to log in before you can comment on or make changes to this bug.