From owner-freebsd-security Sun Aug 10 20:04:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04278 for security-outgoing; Sun, 10 Aug 1997 20:04:37 -0700 (PDT) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04260 for ; Sun, 10 Aug 1997 20:04:26 -0700 (PDT) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA04920; Mon, 11 Aug 1997 13:02:34 +1000 (EST) From: Warren Toomey Message-Id: <199708110302.NAA04920@henry.cs.adfa.oz.au> Subject: Re: Inetd dumped core - why? To: dbaker@wrangler.cuckoo.com (Daniel Baker) Date: Mon, 11 Aug 1997 13:02:34 +1000 (EST) Cc: freebsd-security@freebsd.org In-Reply-To: <199708110223.VAA00392@wrangler.cuckoo.com> from Daniel Baker at "Aug 10, 97 09:23:18 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article by Daniel Baker: > Did you look in /var/log/messages ? > There may be a reason in there as to why it died. I did, nothing logged there. The kernel logged the following: Aug 8 23:38:45 minnie /kernel: pid 89 (inetd), uid 0: exited on signal 11 which matches the core file: -rw------- 1 root wheel 208896 Aug 8 23:38 /Inetd.core (renamed) Sig 11 is of course SIGSEGV. gdb on inetd using the above core file gives: Core was generated by `inetd'. Program terminated with signal 11, Segmentation fault. #0 0x1d2f in main (argc=0, argv=0xefbfdeac, envp=0xefbfdeb4) at inetd.c:394 394 ctrl = sep->se_fd; and sep has a value of 0x2. The code leading up to this is: for (sep = servtab; n && sep; sep = sep->se_next) if (sep->se_fd != -1 && FD_ISSET(sep->se_fd, &readable)) { n--; if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) { /* BRANCH NOT TAKEN */ L51: .stabd 68,0,393 jmp L53 .align 2,0x90 } else (3 prev asm lines) L45: .stabd 68,0,394 movl -4(%ebp),%eax movl 112(%eax),%edx movl %edx,-224(%ebp) ctrl = sep->se_fd; (4 prev asm lines) The regs are: eax 0x34da 13530 ecx 0xefbfdd74 -272638604 edx 0x0 0 ebx 0x34da 13530 esp 0xefbfdd84 0xefbfdd84 ebp 0xefbfde84 0xefbfde84 esi 0x13700 79616 edi 0xc 12 eip 0x1d2f 0x1d2f ps 0x10202 66050 cs 0x1f 31 ss 0x27 39 ds 0xefbf0027 -272695257 es 0x10027 65575 I'm wondering if this is a stack overflow attack. Many of the local variables have very strange values: struct servtab *sep; 0x2 struct passwd *pwd; Cannot access memory at address 0x82001 struct sigvec sv; {sv_handler = 0xffffffff , sv_mask = 3, sv_flags = 8108} int tmpint, ch, dofork; 134238208, 0, 0 pid_t pid; 32 char buf[50]; {0xa8, 0xde, 0xbf, 0x0, 0x90, 0xde, 0xbf, 0xef, 0x60, 0x14, 0x0, 0x0, 0x40, 0x6d, 0x0, 0x8, 0xac, 0xde, 0xbf, 0xef, 0xa8, 0xde, 0xbf, 0xef, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0xcc, 0x0, 0x86, 0xc0, 0x0, 0xd0, 0x0, 0x0, 0x0, 0x20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} struct sockaddr_in peer; Seems ok, base address is 0xefbfde1c int i; -272638420 Finally, strings on inetd.core gives: $Id: inetd.c,v 1.6.2.2 1996/10/28 23:03:54 joerg Exp $ Hope this helps! Warren