Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Aug 1997 13:02:34 +1000 (EST)
From:      Warren Toomey <wkt@henry.cs.adfa.oz.au>
To:        dbaker@wrangler.cuckoo.com (Daniel Baker)
Cc:        freebsd-security@freebsd.org
Subject:   Re: Inetd dumped core - why?
Message-ID:  <199708110302.NAA04920@henry.cs.adfa.oz.au>
In-Reply-To: <199708110223.VAA00392@wrangler.cuckoo.com> from Daniel Baker at "Aug 10, 97 09:23:18 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
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 <end+4294774183>,
				 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708110302.NAA04920>