Date: Tue, 11 May 1999 19:39:08 +0200 (CEST) From: Pierre Beyssac <pb@fasterix.freenix.org> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/11651: inetd's childs staying around after a scan Message-ID: <199905111739.TAA82788@fasterix.frmug.org>
next in thread | raw e-mail | index | archive | help
>Number: 11651
>Category: bin
>Synopsis: inetd's childs staying around after a scan
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue May 11 10:40:01 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator: Pierre Beyssac
>Release: FreeBSD 4.0-CURRENT i386
>Organization:
individual
>Environment:
-current as of May 1st
inetd using hosts.allow and hosts.deny
>Description:
Summary: several forked childs for the echo datagram service staying
around. One of them logs EBADF errors in select(2). The others
are stuck in a recvfrom.
Details: I was recently the victim of a UDP (+ probably TCP) scan.
After the fact, I noticed that I had many (about 20) hung inetd
around, all childs of the "main" inetd (unfortunately I've
been unable to find a way to reproduce the problem so far).
Most of them are stuck at the following place: recvfrom() in the
echo datagram service (the weird thing being that the echo
datagram service is not supposed to fork):
0x280a9330 in _recvfrom ()
(gdb) where
#0 0x280a9330 in _recvfrom ()
#1 0x804b88f in echo_dg (s=13, sep=0x8057900)
at /u2/usr/src/usr.sbin/inetd/inetd.c:1670
#2 0x8049fba in main (argc=1, argv=0xbfbfde0c, envp=0xbfbfde14)
at /u2/usr/src/usr.sbin/inetd/inetd.c:656
#3 0x8049689 in _start ()
One of the forked inetd's (not the father) periodically logs the
following, which alerted me to the problem:
May 7 03:23:32 fasterix inetd[24557]: select: Bad file descriptor
Same process in gdb:
#0 0x280a8630 in nanosleep ()
#1 0x280c3c2b in sleep ()
#2 0x8049a6d in main (argc=1, argv=0xbfbfde0c, envp=0xbfbfde14)
at /u2/usr/src/usr.sbin/inetd/inetd.c:485
#3 0x8049689 in _start ()
Breakpoint 2, main (argc=1, argv=0xbfbfde0c, envp=0xbfbfde14)
at /u2/usr/src/usr.sbin/inetd/inetd.c:484
484 syslog(LOG_WARNING, "select: %m");
(gdb) print maxsock
$1 = 20
(gdb) print allsock
$2 = {fds_bits = {2097144, 0 <repeats 31 times>}}
Equivalent bitmask: 1 1111 1111 1111 1111 1000
fstat yields the following for all child processes:
root inetd 24557 root / 2 drwxr-xr-x 1024 r
root inetd 24557 wd / 2 drwxr-xr-x 1024 r
root inetd 24557 text /u2 500641 -r-xr-xr-x 21548 r
root inetd 24557 0 / 107 crw-rw-rw- null rw
root inetd 24557 1 / 107 crw-rw-rw- null rw
root inetd 24557 2 / 107 crw-rw-rw- null rw
root inetd 24557 3* local dgram c49d73c0 <-> c49d7fc0
root inetd 24557 13* internet dgram udp c4455840
root inetd 24557 21* internet dgram udp c4455660
root inetd 24557 22* pipe c49d2d40 <-> c49d2de0 0 rw
>How-To-Repeat:
Unknown yet. It's not enough to just flood echo/chargen and friends
with datagrams.
Note that the forking/not forking behaviour seems to be affected
by libwrap configuratin as shown by the following from inetd.c:
#ifdef LIBWRAP_INTERNAL
dofork = 1;
#else
dofork = (sep->se_bi == 0 || sep->se_bi->bi_fork);
#endif
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905111739.TAA82788>