The vulnerability is caused due to an unspecified error and can be exploited to corrupt heap memory. Solution: Update to version 4.42.
CVE-2011-2940 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-2940): stunnel 4.40 and 4.41 might allow remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors.
The listen-queue patch is now upstream. I've had hoped to get the x-forwarded-for patch upstream too, but the author is unsatisfied with it's quality and unwilling to merge it, though there are several people in the haproxy community (including me) using the patch in production without problems. He is actually searching for someone that sponsors him the development of a patch of better quality that does everything right(tm). :/ I'm sorry about that, but in order to be able to provider faster bumps for security fixes, we should punt the x-forwarded-for patch. Beginning with stunnel-4.45, stunnel will have "sendproxy" support, making x-forwarded-for obsolete for the haproxy-community anyways, meaning that there will be much less interest in providing patches for newer stunnel versions. @ramerath: I'm sorry for the hassle with the package, can you provide an updated ebuild?
stunnel-4.44 in the tree now, with BOTH patches because they are used.
Thanks Robin and Stefan. Arches, please test and mark stable: =net-misc/stunnel-4.44 target KEYWORDS : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
@Robin, Lance: I'm not a guru with this program, but it seems does not working properly; frmo my shell: amd64box ~ # /etc/init.d/stunnel start stunnel | * Starting stunnel ... stunnel |No limit detected for the number of clients stunnel |signal_pipe: FD=3 allocated (non-blocking mode) stunnel |signal_pipe: FD=4 allocated (non-blocking mode) stunnel |stunnel 4.44 on x86_64-pc-linux-gnu platform stunnel |Compiled/running with OpenSSL 1.0.0e 6 Sep 2011 stunnel |Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6 stunnel |Reading configuration from file /etc/stunnel/stunnel.conf stunnel |PRNG seeded successfully stunnel |Line 61: End of section stunnel: SSL server needs a certificate stunnel |str_stats: 41 block(s), 1478 data byte(s), 2050 control byte(s) [ ok ] Now it seems started: amd64box ~ # /etc/init.d/stunnel status * status: started but I didn't see pid: amd64box ~ # ls /var/run/stunnel/ amd64box ~ # and ps aux does not returns anything: amd64box ~ # ps aux | grep stunnel root 26933 0.0 0.0 6288 576 pts/1 S+ 00:46 0:00 grep --colour=auto stunnel So I think that if is not running, status shouldn't be return [ok]. Can you provide more info to test? or is enough compile test?TIA
Please wait with stabilization until further testing of the new ebuild was done.
(In reply to comment #6) > Please wait with stabilization until further testing of the new ebuild was > done. I'm available for testing after ebuild changement.
The root cause of agos testing failure seems to be that he didn't test with a proper configuration. I'm sorry for not looking into this earlier. stunnel-4.44 works just fine for me. Arches, please test and mark stable: =net-misc/stunnel-4.44 target KEYWORDS : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Actually adding arches now; please test and mark stable: =net-misc/stunnel-4.44 target KEYWORDS : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
x86 stable
ppc/ppc64 stable
amd64 all appears ok; emerges, starts and stops archtester xen-tools # rc-status |grep stunnel stunnel [ started ]
amd64 done. Thanks Ian
arm stable
Stable for HPPA.
alpha/ia64/s390/sparc stable
Thanks all. Glsa request filed.
Our lazy GLSA bot does not want to update the bug, so I have to do it manually. GLSA sent. Closing.
Now really closing.
This issue was resolved and addressed in GLSA 201202-08 at http://security.gentoo.org/glsa/glsa-201202-08.xml by GLSA coordinator Stefan Behte (craig).
Today, glsa-check reports that my system would be affected by a vulnerability in net-misc/stunnel-3.26. However, the upstream bug clearly states that only versions 4.40 and 4.41 are affected, so it is a false positive. Could the GLSA be fixed please, such that stunnel-3* is excepted from the list of vulnerable versions? Reopening.
(In reply to comment #22) > > Reopening. File a new bug in the GLSA errors category, please.
