From owner-freebsd-security@FreeBSD.ORG Fri Apr 18 12:50:21 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BFD837B401 for ; Fri, 18 Apr 2003 12:50:21 -0700 (PDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D08043FCB for ; Fri, 18 Apr 2003 12:50:20 -0700 (PDT) (envelope-from apeiron@comcast.net) Received: from [192.168.0.8] (pcp01380957pcs.levtwn01.pa.comcast.net [68.81.162.166]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) security@freebsd.org; Fri, 18 Apr 2003 15:49:50 -0400 (EDT) Date: Fri, 18 Apr 2003 15:50:43 -0400 From: Christopher Nehren To: security@freebsd.org Message-id: <1050695443.1534.86.camel@prophecy.dyndns.org> Organization: MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-type: multipart/signed; boundary="=-UAyFFoFwA0lfjZ85hTzG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: [Fwd: Xinetd 2.3.10 Memory Leaks] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 19:50:21 -0000 --=-UAyFFoFwA0lfjZ85hTzG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I just submitted a PR for this (haven't even gotten the confirmation email), but since not everyone tracks the GNATS CVS distribution, I figured that I'd send it here as well. -----Forwarded Message----- > From: Steve Grubb > To: bugtraq@securityfocus.com > Subject: Xinetd 2.3.10 Memory Leaks > Date: 18 Apr 2003 16:18:36 +0000 >=20 >=20 >=20 > BACKGROUND >=20 > ----------- >=20 >=20 >=20 > Xinetd is a popular inetd replacement. Shortly after the 2.3.9 release in= =20 >=20 > September 2002, it was realized that xinetd was leaking file descriptors.= =20 >=20 > That problem turned out to be that file descriptors were not always being= =20 >=20 > closed whenever a connection was rejected. 2.3.10 was released with this=20 >=20 > fixup among others in January. >=20 >=20 >=20 > Sometime in February, a machine that I admin was hit by an ftp worm. It=20 >=20 > created > 5000 connections in 1 second. Xinetd promptly keeled over.=20 >=20 > Xinetd had been running for over a month with no downtime. The machine ha= s=20 >=20 > next to no ftp traffic and only from 2 sources, so it was configured to b= e=20 >=20 > run via xinetd rejecting connections via tcp_wrappers. The machine had=20 >=20 > weathered worm attacks in the past, so this puzzled me. >=20 >=20 >=20 >=20 >=20 > TESTING >=20 > ------- >=20 >=20 >=20 > Eventually, I started looking at xinetd with valgrind. I used the=20 >=20 > following commandline: >=20 >=20 >=20 > valgrind --leak-check=3Dyes --leak-resolution=3Dmed --num-callers=3D8 \ >=20 > --logfile-fd=3D9 /usr/sbin/xinetd -d -pidfile /var/run/xinetd.pid \ >=20 > -stayalive 9> out.txt >=20 >=20 >=20 > Depending on your setup, you may need to use something higher than 9.=20 >=20 > Xinetd was tested on connections that succeed and connections that are=20 >=20 > rejected due to configuration settings. The easiest way to test this is t= o=20 >=20 > use the following setup for chargen: >=20 >=20 >=20 > service chargen >=20 > { >=20 > type =3D INTERNAL >=20 > user =3D root >=20 > protocol =3D tcp >=20 > wait =3D no >=20 > access_times =3D 2:00-3:00 >=20 > # only_from =3D 192.168.1.3/24 >=20 > # no_access =3D 192.168.1.3/24 >=20 > } >=20 >=20 >=20 > The point is to set it up in a way that the connection is guaranteed to b= e=20 >=20 > rejected. Then do a: >=20 >=20 >=20 > telnet localhost chargen >=20 > After a couple seconds "ctl-] quit" >=20 > Then, /etc/rc.d/init.d/xinetd stop >=20 >=20 >=20 > Valgrind reports the following: >=20 >=20 >=20 > =3D=3D18939=3D=3D 144 bytes in 1 blocks are definitely lost in loss recor= d 36 of 45 >=20 > =3D=3D18939=3D=3D at 0x40160DB8: malloc (vg_clientfuncs.c:103) >=20 > =3D=3D18939=3D=3D by 0x804FE22: (within /usr/sbin/xinetd) >=20 > =3D=3D18939=3D=3D by 0x805A496: (within /usr/sbin/xinetd) >=20 > =3D=3D18939=3D=3D by 0x8053611: (within /usr/sbin/xinetd) >=20 > =3D=3D18939=3D=3D by 0x805340D: (within /usr/sbin/xinetd) >=20 > =3D=3D18939=3D=3D by 0x40294A46: __libc_start_main (in /lib/libc-2.3.2= .so) >=20 > =3D=3D18939=3D=3D by 0x804A310: (within /usr/sbin/xinetd) >=20 > =3D=3D18939=3D=3D >=20 > =20 >=20 >=20 >=20 > THE PROBLEM >=20 > ----------- >=20 > =20 >=20 > Using objdump -S /usr/sbin/xinetd, the block of code in question comes=20 >=20 > from service.c: >=20 >=20 >=20 > void svc_request( struct service *sp ) >=20 > { >=20 > connection_s *cp ; >=20 > status_e ret_code; >=20 > = =20 >=20 > =20 >=20 > cp =3D conn_new( sp ) ; >=20 > if ( cp =3D=3D CONN_NULL ) >=20 > return ; >=20 > if (sp->svc_not_generic) >=20 > ret_code =3D spec_service_handler(sp, cp); >=20 > else >=20 > ret_code =3D svc_generic_handler(sp, cp); >=20 > = =20 >=20 > =20 >=20 > if ( ret_code !=3D OK ) >=20 > { >=20 > if ( SVC_LOGS_USERID_ON_FAILURE( sp ) ) >=20 > if( spec_service_handler( LOG_SERVICE( ps ), cp ) =3D=3D FAILED = ) { >=20 > conn_free( cp, 1 ); >=20 > return; >=20 > } >=20 > CONN_CLOSE(cp); >=20 > } >=20 > } >=20 >=20 >=20 > The above code has several problems. One background piece of information=20 >=20 > is that the sigchld handler in xinetd (child_exit->server_end->=20 >=20 > svc_postmortem) normally frees the connection's data. If the ret_code is=20 >=20 > not OK, the connection was only closed. This is little more than close(cp= - >=20 > >co_descriptor); This does not free cp since sigchld will not be called.=20 >=20 > It was only if the log service call failed that the connection was freed.= =20 >=20 >=20 >=20 > The above code also did not take into account ret_code =3D=3D OK if the=20 >=20 > service was no_wait or special. In both of those cases, the sigchld=20 >=20 > handler is not invoked so the memory pointed to by cp is lost when the=20 >=20 > call returns. >=20 >=20 >=20 >=20 >=20 > CONSEQUENCES >=20 > ------------ >=20 >=20 >=20 > The memory area pointed to by cp is 144 bytes. Since the variable goes ou= t=20 >=20 > of scope, it is permanently lost with no way of finding it again. The=20 >=20 > memory losses are cumulative, too. It would take little more than >=20 >=20 >=20 > while true; do telnet localhost chargen < /dev/null; done; >=20 >=20 >=20 > to DOS the services provided by xinetd if you could identify a machine=20 >=20 > that uses xinetd to reject connections. Xinetd provides a rich set of=20 >=20 > options for rejecting connections, this includes: tcp_wrappers, only_from= ,=20 >=20 > no_access, sensors, access_times, cps, load_avg, etc. >=20 >=20 >=20 > It should also be noted that if you DO NOT have any statements in the=20 >=20 > xinetd.conf file that would cause xinetd to reject a connection, then you= =20 >=20 > are free from this problem. >=20 >=20 >=20 >=20 >=20 > SOLUTION >=20 > -------- >=20 >=20 >=20 > Xinetd 2.3.11 fixes the memory leaks as well as other problems discovered= =20 >=20 > since 2.3.10 was released. All users of xinetd 2.3.10 are strongly urged=20 >=20 > to upgrade ASAP to avoid DOS conditions. Anyone running 2.3.9 is also=20 >=20 > strongly urged to upgrade since they are leaking file descriptors. >=20 >=20 >=20 > Your xinetd version can be determined by typing "xinetd -version" (that's= =20 >=20 > version with 1 dash). >=20 >=20 >=20 > The new tarball is: www.xinetd.org/xinetd-2.3.11.tar.gz >=20 >=20 >=20 > This problem has been assigned CAN-2003-0211 to track the bug.=20 >=20 >=20 >=20 > This bug was also reported here:=20 >=20 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D88537 >=20 >=20 >=20 > If you are affected, see if your vendor has an updated xinetd for you. >=20 >=20 >=20 > -Steve Grubb >=20 >=20 >=20 --=-UAyFFoFwA0lfjZ85hTzG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQA+oFcTUdqurN0fljsRAqeYAKC//nn/3oldlm7F7GoSN6VoLZ8vkwCgmhti XgcgF3V3vWS5wmsDiwHX7Lc= =1ak7 -----END PGP SIGNATURE----- --=-UAyFFoFwA0lfjZ85hTzG--