Subject: pkg/23245: security/stunnel does not terminate
To: None <gnats-bugs@gnats.netbsd.org>
From: Hauke Fath <hf@spg.tu-darmstadt.de>
List: netbsd-bugs
Date: 10/23/2003 14:31:01
>Number: 23245
>Category: pkg
>Synopsis: security/stunnel does not terminate properly.
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: pkg-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Oct 23 12:32:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Hauke Fath <hf@spg.tu-darmstadt.de>
>Release: NetBSD 1.6ZC
>Organization:
--
Hauke Fath /~\ The ASCII Ribbon Campaign
Institut für Nachrichtentechnik \ / No HTML/RTF in email
TU Darmstadt X No Word docs in email
Ruf +49-6151-16-3281 / \ Respect for open standards
>Environment:
System: NetBSD heiligenberg 1.6ZC NetBSD 1.6ZC (HEILIGENBERG) #1: Fri Sep 26 16:51:05 CEST 2003 hf@heiligenberg:/var/obj/netbsd-builds/i386/obj/sys/arch/i386/compile/HEILIGENBERG i386
Architecture: i386
Machine: i386
I see the same thing on a NetBSD/sparc 1.6.1 machine.
[hf@heiligenberg] ~ # stunnel -version
stunnel 4.04 on i386--netbsdelf FORK+LIBWRAP with OpenSSL 0.9.7b 10 Apr 2003
Global options
cert = /etc/stunnel/stunnel.pem
ciphers = ALL:!ADH:+RC4:@STRENGTH
debug = 5
key = /etc/stunnel/stunnel.pem
pid = /usr/pkg/var/run/stunnel.pid
RNDbytes = 64
RNDfile = /dev/urandom
RNDoverwrite = yes
session = 300 seconds
verify = none
Service-level options
TIMEOUTbusy = 300 seconds
TIMEOUTclose = 60 seconds
TIMEOUTidle = 43200 seconds
[hf@heiligenberg] ~ # cat /etc/uucp/stunnel.conf
# $Id: stunnel.conf,v 1.3 2003/09/08 21:16:52 hauke Exp hf $
#
# stunnel setup for uucp client
debug = mail.info
client = yes
pid =
[uucico]
connect = uucp.XXXXX.YYY:940
exec = /usr/libexec/uucp/uucico
execargs = uucico --nodetach --nouuxqt --debug abnormal -S uucp
>Description:
After updating stunnel 3.xx to version 4, stunnel processes
keep hanging around indefinitely after the uucico job is done,
both in the background and in the foreground (option
'foreground = yes'). With two uucp connects per hour, this
gets annoying quickly.
This did not happen with stunnel 3.xx. Since the stunnel group
mis-designed other things (removing the cli options, for one),
can we have an stunnel3 package?
>How-To-Repeat:
Do an 'stunnel /etc/uucp/stunnel.conf', see the job does not
terminate when in the foreground, and processes keep hanging
around when started as a daemon.
Attach gdb:
(gdb) bt
#0 0x481c454b in select () from /usr/lib/libc.so.12
#1 0x8051032 in sselect (n=4, readfds=0xbfbff344, writefds=0x0,
exceptfds=0x0, timeout=0x0) at sselect.c:85
#2 0x8052bc0 in daemon_loop () at stunnel.c:195
#3 0x80527b9 in main_execute () at stunnel.c:105
#4 0x80526db in main (argc=2, argv=0xbfbff424) at stunnel.c:72
#5 0x804a594 in ___start ()
(gdb) up
#1 0x8051032 in sselect (n=4, readfds=0xbfbff344, writefds=0x0,
exceptfds=0x0, timeout=0x0) at sselect.c:85
85 retval=select(n, readfds, writefds, exceptfds, NULL);
(gdb) info frame
Stack level 1, frame at 0xbfbff2e4:
eip = 0x8051032 in sselect (sselect.c:85); saved eip 0x8052bc0
called by frame at 0xbfbff394, caller of frame at 0xbfbff2e4
source language c.
Arglist at 0xbfbff2e4, args: n=4, readfds=0xbfbff344, writefds=0x0,
exceptfds=0x0, timeout=0x0
Locals at 0xbfbff2e4, Previous frame's sp is 0x0
Saved registers:
ebx at 0xbfbff2cc, ebp at 0xbfbff2e4, eip at 0xbfbff2e8
(gdb)
>Fix:
Set up a cron job that kills the rogue stunnel processes, or
roll back to stunnel 3.
Or, fix stunnel.
>Release-Note:
>Audit-Trail:
>Unformatted: