From owner-freebsd-security Sun Jun 9 02:54:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25747 for security-outgoing; Sun, 9 Jun 1996 02:54:21 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25723 for ; Sun, 9 Jun 1996 02:54:18 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id DAA11025; Sun, 9 Jun 1996 03:54:15 -0600 From: Ade Barkah Message-Id: <199606090954.DAA11025@hemi.com> Subject: Re: FreeBSD's /var/mail permissions To: taob@io.org (Brian Tao) Date: Sun, 9 Jun 1996 03:54:15 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 01:29:23 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: > On Fri, 7 Jun 1996, Karl Denninger, MCSNet wrote: > > > > Does this mean we should give up on using mail? > > No, it means you keep mail on a separate machine and manipulate > your mailbox through a server like POP3 or IMAP. But this is what started the thread, right ? With the current scheme qpop 2.2 will not work with FreeBSD; at least not for new users (it doesn't have enough permissions to set up the per-mailbox lock file.) -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 08:46:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01281 for security-outgoing; Sun, 9 Jun 1996 08:46:36 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA01262 for ; Sun, 9 Jun 1996 08:46:33 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA10038; Sun, 9 Jun 1996 08:44:46 -0700 (PDT) Message-Id: <199606091544.IAA10038@precipice.shockwave.com> To: Ade Barkah cc: taob@io.org (Brian Tao), security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Sun, 09 Jun 1996 03:54:15 MDT." <199606090954.DAA11025@hemi.com> Date: Sun, 09 Jun 1996 08:44:44 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just restored the old behavior as part of qpop2.2. I think going to /var/mail is useless given that chown() is restricted. From: Ade Barkah Subject: Re: FreeBSD's /var/mail permissions Brian Tao wrote: > On Fri, 7 Jun 1996, Karl Denninger, MCSNet wrote: > > > > Does this mean we should give up on using mail? > > No, it means you keep mail on a separate machine and manipulate > your mailbox through a server like POP3 or IMAP. But this is what started the thread, right ? With the current scheme qpop 2.2 will not work with FreeBSD; at least not for new users (it doesn't have enough permissions to set up the per-mailbox lock file.) -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 08:57:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA04040 for security-outgoing; Sun, 9 Jun 1996 08:57:09 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA04022 for ; Sun, 9 Jun 1996 08:57:05 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id LAA12444; Sun, 9 Jun 1996 11:56:05 -0400 (EDT) Date: Sun, 9 Jun 1996 11:56:10 -0400 (EDT) From: Brian Tao To: Ade Barkah cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606090954.DAA11025@hemi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Ade Barkah wrote: > > But this is what started the thread, right ? With the current scheme > qpop 2.2 will not work with FreeBSD; at least not for new users (it > doesn't have enough permissions to set up the per-mailbox lock file.) There is the general case of wanting non-setuid programs vs. write-protected directories. The POP daemon case was one specific example of that. I already have enough files in /var/mail, so I've always used /var/mail/.tmp (yes, we have a user named tmp@io.org, *sigh*). It is world writeable, but I have a separate mail server that is secured from user logins, so it isn't a problem here. An alternative would be to modify your newuser procedure to touch and chown a .pop lock file for the user and configure your POP server not to remove those files when the user exits. From the qpopper 2.2 install notes: h) KEEP_TEMP_DROP - Keep the .user.pop file around. It can be used to determine when the last time a user has accessed their mail. [...] 3) When qpopper runs it moves your mailspool to a temporary location (.user.pop). The default location is in the mail spool directory. /tmp is an alternative but is consider to be a security risk and a system reboot will probably clear the temporary .user.pop files. For performance reasons a sysadmin who has many users (say 1000 or more) can create a separate spool directory for popper files. /usr/spool/poptemp could be a good choice. Permissions should the same as your mailspool as well as the same owner and group. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 09:03:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05842 for security-outgoing; Sun, 9 Jun 1996 09:03:55 -0700 (PDT) Received: from cs.pdx.edu (root@cs.pdx.edu [204.203.64.22]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05827 for ; Sun, 9 Jun 1996 09:03:51 -0700 (PDT) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13]) by cs.pdx.edu (8.7.3/CATastrophe-2/10/96-P) with ESMTP id JAA14924; Sun, 9 Jun 1996 09:01:06 -0700 (PDT) for Received: from localhost (jrb@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.7.3/CATastrophe-9/18/94-C) with ESMTP id JAA29242; Sun, 9 Jun 1996 09:03:48 -0700 (PDT) Message-Id: <199606091603.JAA29242@sirius.cs.pdx.edu> To: Steve Reid cc: freebsd-security@FreeBSD.org Subject: Re: MD5 broken In-reply-to: Your message of "Fri, 07 Jun 1996 17:05:25 PDT." Date: Sun, 09 Jun 1996 09:03:47 -0700 From: Jim Binkley Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I'm afraid I'm going to muddy the waters a bit... I have been following the IETF IPSEC (Ip layer security) group for a long time (seems like a long time...). E.g., see RFCS 1825-1829. IPSEC has designed two headers for security, AH (authentication) and ESP (encryption/privacy), with the assumption that these headers would be used in ipv4 and ipv6. "Transforms" (i.e., specific algorithms for specific crypto algorithms more or less) for the headers have been defined too; e.g., for ESP the transform is *changing* from DES-CBC to an authenticated version of DES-CBC. With AH, the transform *was* keyed MD5 (see RFC1828.txt). IPSEC has decided that keyed MD5 needs to be retired, primarily because of paranoia over the attacks described. There are going to be two required replacements, hmac-md5, and hmac-sha. hmac-md5 and hmac-sha could loosely be described as tougher versions of keyed-md5. If you want to look at the drafts for said transforms, visit an Internet ftp site (e.g., ftp://ftp.isi.edu/internet-drafts) and look at: draft-ietf-ipsec-ah-hmac-sha-00.txt draft-ietf-ipsec-ah-hmac-md5-00.txt The above is just fyi on the situation. Now for an opinion. I agree with Poul-Henning Kemp. The situation isn't that serious at the moment. IPSEC has several kinds of people in it at least, cryptographers (not me), security types, and network engineers (i'll accept that). Crypto people are paranoid by definition and IPSEC has to worry about both ipv4 and v6 long-term. On the other hand, it may be itime to start thinking about a replacement. Over time, all crypto algorithms will have to get stronger as computers get more powerful. regards, Jim Binkley jrb@cs.pdx.edu psu cs dept. From owner-freebsd-security Sun Jun 9 09:14:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08095 for security-outgoing; Sun, 9 Jun 1996 09:14:20 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08089 for ; Sun, 9 Jun 1996 09:14:17 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id MAA12561 for ; Sun, 9 Jun 1996 12:13:19 -0400 (EDT) Date: Sun, 9 Jun 1996 12:13:24 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Effects of kern.securelevel >= 0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to /sys/sys/systm.h, single user mode should be associated with kern.securelevel=0 and multiuser mode with kern.securelevel=1. Should the default /etc/rc have the appropriate sysctl call? Also, are there any caveats to running an ISP shell login server with securelevel 2? I recall that an old version of XFree86 would complain at level 1+ because it seemed to want to write to /dev/mem (VGA memory access?). I can't think of any side effects (no user should be fiddling with raw disk devices anyway). My main concern was the ability to turn off schg/sappnd flags at level -1 or 0. I suppose, however, that if someone was able to execute commands as root, that person could just add commands to /etc/rc to do their dirty deeds and reboot the machine... :( /* * The `securelevel' variable controls the security level of the system. * It can only be decreased by process 1 (/sbin/init). * * Security levels are as follows: * -1 permanently insecure mode - always run system in level 0 mode. * 0 insecure mode - immutable and append-only flags make be turned off. * All devices may be read or written subject to permission modes. * 1 secure mode - immutable and append-only flags may not be changed; * raw disks of mounted filesystems, /dev/mem, and /dev/kmem are * read-only. * 2 highly secure mode - same as (1) plus raw disks are always * read-only whether mounted or not. This level precludes tampering * with filesystems by unmounting them, but also inhibits running * newfs while the system is secured. * * In normal operation, the system runs in level 0 mode while single user * and in level 1 mode while multiuser. If level 2 mode is desired while * running multiuser, it can be set in the multiuser startup script * (/etc/rc.local) using sysctl(1). If it is desired to run the system * in level 0 mode while multiuser, initialize the variable securelevel * in /sys/kern/kern_sysctl.c to -1. Note that it is NOT initialized to * zero as that would allow the kernel binary to be patched to -1. * Without initialization, securelevel loads in the BSS area which only * comes into existence when the kernel is loaded and hence cannot be * patched by a stalking hacker. */ -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 13:45:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19792 for security-outgoing; Sun, 9 Jun 1996 13:45:06 -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 NAA19762 for ; Sun, 9 Jun 1996 13:44:58 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA08601; Sun, 9 Jun 1996 16:44:52 -0400 Date: Sun, 9 Jun 1996 16:44:52 -0400 From: Garrett Wollman Message-Id: <9606092044.AA08601@halloran-eldar.lcs.mit.edu> To: Brian Tao Cc: FREEBSD-SECURITY-L Subject: Effects of kern.securelevel >= 0 In-Reply-To: References: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > According to /sys/sys/systm.h, single user mode should be > associated with kern.securelevel=0 and multiuser mode with > kern.securelevel=1. Should the default /etc/rc have the appropriate > sysctl call? No. It is automatically increased by init if it starts out as >=0. Like the comment in the file says, you should delete the initializer in the source file if you want to enable security features. > Also, are there any caveats to running an ISP shell login server > with securelevel 2? I recall that an old version of XFree86 would > complain at level 1+ because it seemed to want to write to /dev/mem > (VGA memory access?). I can't think of any side effects (no user > should be fiddling with raw disk devices anyway). Unfortunately, there are still a number of other holes, like /dev/io, that would need to be closed before this was a truly ``safe'' environment. > My main concern was the ability to turn off schg/sappnd flags at > level -1 or 0. I suppose, however, that if someone was able to > execute commands as root, that person could just add commands to > /etc/rc to do their dirty deeds and reboot the machine... :( That's why, when setting up a secure system, you have to make /etc/rc, and all the files it depends on, immutable, and all the important system directories append-only. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Sun Jun 9 15:07:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27372 for security-outgoing; Sun, 9 Jun 1996 15:07:17 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA27366 for ; Sun, 9 Jun 1996 15:07:13 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id QAA24430; Sun, 9 Jun 1996 16:06:55 -0600 From: Ade Barkah Message-Id: <199606092206.QAA24430@hemi.com> Subject: Re: FreeBSD's /var/mail permissions To: taob@io.org (Brian Tao) Date: Sun, 9 Jun 1996 16:06:55 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 11:56:10 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: [Regarding QPOP not having permissions to create lock files] > An alternative would be to modify your newuser procedure to touch > and chown a .pop lock file for the user and configure your POP server > not to remove those files when the user exits. This is what I do currently; it feels like such a bad hack. > From the qpopper 2.2 install notes: > > h) KEEP_TEMP_DROP - Keep the .user.pop file around. It can be > used to determine when the last time a user has > accessed their mail. Actually, this is not needed. The same set of permissions which prevents QPOP from creating the .user.pop file also prevents it from removing the lock file. =-) Off topic, I keep getting these syslog messages from QPOP: popper[20737]: @remote-host: -ERR POP EOF received Any ideas why this might be happening ? I'm sure I'm not the only one seeing many of these. It seems like a chronic problem on the client side. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 16:13:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA06921 for security-outgoing; Sun, 9 Jun 1996 16:13:49 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA06914 for ; Sun, 9 Jun 1996 16:13:47 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id BAA08704 for security@FreeBSD.org; Mon, 10 Jun 1996 01:13:30 +0200 Message-Id: <199606092313.BAA08704@sea.campus.luth.se> Subject: Re: FreeBSD's /var/mail permissions To: security@FreeBSD.org Date: Mon, 10 Jun 1996 01:13:30 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: <199606081506.IAA05615@precipice.shockwave.com> from "Paul Traina" at Jun 8, 96 08:06:48 am X-Mailer: ELM [version 2.4 PL25 ME8b] 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 > Excellent point. :-( [...] > > Proposed solution: > > I'm considering creating group "mail" and going the setgid route, > > so that a program which creates files in /var/mail can be simply > > setgid mail. > > > > This is a well understood mail directory protection mechanism > > and employs the "principle of least privilege." > > I don't think so. Unlike SysV, you cannot chown a file to a user of > your will except when being root. So IMHO this does already mandate > the programs that create mail folders to be setuid root. Given this, > there's no sense in using the group `mail' in addition. Er... Excellent point? Why in the WORLD would you want to chown the files for? If a program wants to lock the mail file, by creating a lock file, or move the mailbox to another name and create a new mailbox, or use some form of temporary file, that file should owned by the same user that is running the program, and not the user at the terminal beside him, no? ;-) And the really neat thing is, if he just creates a file in mail with a "setgid mail" program, it will be created and... *drumroll* ...already be for the right user! No need to chown, is there? Provided /var/mail is 775 root:mail and the program is setgid mail. Only mail.local needs to be root still, because it is not invoked by the user who's mailbox it's going to edit. Seems the setgid and 775 root:mail /var/mail is the excellent idea, to me. /Mikael From owner-freebsd-security Sun Jun 9 16:20:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA08184 for security-outgoing; Sun, 9 Jun 1996 16:20:48 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA08175 for ; Sun, 9 Jun 1996 16:20:45 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id BAA08721 for security@FreeBSD.org; Mon, 10 Jun 1996 01:20:29 +0200 Message-Id: <199606092320.BAA08721@sea.campus.luth.se> Subject: Re: FreeBSD's /var/mail permissions To: security@FreeBSD.org Date: Mon, 10 Jun 1996 01:20:29 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: <199606081504.IAA05536@precipice.shockwave.com> from "Paul Traina" at Jun 8, 96 08:04:43 am X-Mailer: ELM [version 2.4 PL25 ME8b] 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 > But bad guy can't, because /var/mail is 755 > > > > I'm confused, why do you say adduser must create new user mailbox? > > > Mail.local is already suid root and adduser should deliver a preformatted > > > mail message with mail.local. > > > > Why should adduser send any mail to anybody? Rather silly if you ask me. > > Because bad guy can pre-create upcoming user mailbox with 666 permissions. No, he can not, correct. Unless you fool some program to. However, I think it seems like a good idea for adduser to touch, chown and chmod the users mailbox when the user is created, ANYWAY. Then you're on the safe side, so you are sure it's correct. If someone feel like changing adduser to do so, it would be great. And while whomever is doing that, please fix so that the users homedirectory is chowned to the user even if you select to not copy the defaults files. The mail to the user is not silly. It can be a welcome message to the user, with instructions and information, for example. And it's up to the admin to choose if he wants to send the mail or not anyway. /Mikael From owner-freebsd-security Sun Jun 9 16:38:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA12294 for security-outgoing; Sun, 9 Jun 1996 16:38:06 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA12278 for ; Sun, 9 Jun 1996 16:38:03 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id TAA15820; Sun, 9 Jun 1996 19:37:00 -0400 (EDT) Date: Sun, 9 Jun 1996 19:37:05 -0400 (EDT) From: Brian Tao To: Ade Barkah cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606092206.QAA24430@hemi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Ade Barkah wrote: > > Actually, this is not needed. The same set of permissions which > prevents QPOP from creating the .user.pop file also prevents it > from removing the lock file. =-) It complains about not being able to remove the file though, doesn't it? I don't know, since I haven't experimented with it (I use a mode 1777 /var/mail/.tmp). > popper[20737]: @remote-host: -ERR POP EOF received > > Any ideas why this might be happening ? I'm sure I'm not the only > one seeing many of these. It seems like a chronic problem on the > client side. Hrmmmm... I remember some sort of problem like that with an older 2.1.x qpopper that forced me to go back to the cac.washington.edu POP daemon. I'm a Pine user myself, so POP-related problems don't usually surface unless I can force myself to use Netscape to read mail (ick!) and look for anomalies. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 16:45:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA13786 for security-outgoing; Sun, 9 Jun 1996 16:45:16 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA13774 for ; Sun, 9 Jun 1996 16:45:14 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id TAA15844; Sun, 9 Jun 1996 19:44:11 -0400 (EDT) Date: Sun, 9 Jun 1996 19:44:16 -0400 (EDT) From: Brian Tao To: Garrett Wollman cc: FREEBSD-SECURITY-L Subject: Re: Effects of kern.securelevel >= 0 In-Reply-To: <9606092044.AA08601@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Garrett Wollman wrote: > > No. It is automatically increased by init if it starts out as >=0. You mean "<= 0"? I haven't fiddled with the default startup value here, and a 'sysctl kern.securelevel' in multiuser mode shows it is still at level -1. > That's why, when setting up a secure system, you have to make /etc/rc, > and all the files it depends on, immutable, and all the important > system directories append-only. This is at kern.securelevel = 1: # ls -ld /dev drwxr-xr-x 3 root wheel - 15360 Jun 9 17:19 /dev # chflags sappnd /dev chflags: /dev: Operation not permitted # ls -ldo /dev drwxr-xr-x 3 root wheel sappnd 15360 Jun 9 17:19 /dev A bogus ENOPERM somewhere? -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 16:46:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA13982 for security-outgoing; Sun, 9 Jun 1996 16:46:13 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA13974 for ; Sun, 9 Jun 1996 16:46:10 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id BAA08788 for security@FreeBSD.org; Mon, 10 Jun 1996 01:45:54 +0200 Message-Id: <199606092345.BAA08788@sea.campus.luth.se> Subject: Re: FreeBSD's /var/mail permissions To: security@FreeBSD.org Date: Mon, 10 Jun 1996 01:45:53 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: <4393.834221631@palmer.demon.co.uk> from "Gary Palmer" at Jun 8, 96 09:13:51 am X-Mailer: ELM [version 2.4 PL25 ME8b] 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 > > Does this mean we should give up on using mail? > > No, it means you should give up on using NFS mounting of /var/mail (or > /var/spool/mail, or wherever else your local OS sticks it). NFS is an > abombination at the best of times, and NFS locking even more so. THere > are far more elegant solutions to the problem of distributing mail to > client workstations, namely IMAP and POP. Sure, it means that people > who use /usr/bin/mail to read their e-mail will be stumped, but I > think that the pro's of using this form of mail distribution far > outweigh the cons. Works fine if you have your own workstation and a program to fetch the files over POP and put on your local machine. However, you could do that with sendmail setup or a .forward file on the server too. The problem is when you don't have your own workstation, but instead a computer lab, where you want to be able to read mail from any of the clients and don't have any storage locally on the workstations. Then you have to NFS mount /var/mail/ to be able to read the same mail on all the machines. if NFS can't handle it, you have a problem. True... But not a problem with /var/mail, but with NFS implementation that needs to be fixed, in that case, I think. > (The fact that my favourite mailer, MH supports POP, SPOP, etc, has > nothing to do with it :-) Elm does not. :P And although it sucks bigtime, it still beats having to use pine, MH, netscape, or something like that, until I manage to find time to write a mailer myself. /Mikael From owner-freebsd-security Sun Jun 9 17:58:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA22998 for security-outgoing; Sun, 9 Jun 1996 17:58:55 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA22987 for ; Sun, 9 Jun 1996 17:58:53 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id UAA16582 for ; Sun, 9 Jun 1996 20:57:51 -0400 (EDT) Date: Sun, 9 Jun 1996 20:57:56 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L Subject: setuid root sendmail vs. mode 1733 /var/spool/mqueue? 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 accidentally went a bit too far today when looking for setuid- related attacks on our 2.2-SNAP shell servers and took the setuid bit off /usr/sbin/sendmail. I only noticed after the schg flag was slapped on everything. :( People were getting 'queuename: Cannot create "qfUAA08787" in "/var/spool/mqueue" (euid=935):' errors for obvious reasons. Since I didn't want to reboot the shell servers just to chmod sendmail, I decided to chmod 1733 /var/spool/mqueue instead: drwx-wx-wt 2 root daemon 2560 Jun 9 20:52 /var/spool/mqueue This allows the non-root sendmails to queue outgoing messages, but prevents other users from snooping the mail spool (mailq is disabled here, and it looks like queue files are mode 600 anyway). The shell servers don't receive any mail themselves, and sendmail runs with a queue processing interval of 5 minutes. Any comments on the validity of my actions? It seems pretty safe to me, and it removes another setuid binary. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 19:14:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA13997 for security-outgoing; Sun, 9 Jun 1996 19:14:27 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA13974 for ; Sun, 9 Jun 1996 19:14:24 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id UAA29892; Sun, 9 Jun 1996 20:14:21 -0600 From: Ade Barkah Message-Id: <199606100214.UAA29892@hemi.com> Subject: Re: FreeBSD's /var/mail permissions To: taob@io.org (Brian Tao) Date: Sun, 9 Jun 1996 20:14:20 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 07:37:05 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: [re: KEEP_DROP_TEMP in QPOP 2.2] > > Actually, this is not needed. The same set of permissions which > > prevents QPOP from creating the .user.pop file also prevents it > > from removing the lock file. =-) > > It complains about not being able to remove the file though, > doesn't it? ... I don't think it does. It erases the file using (void)unlink(p->temp_drop); so it never checks for EACCESS. I should compile with KEEP_DROP_TEMP anyway, more efficient that way. > > popper[20737]: @remote-host: -ERR POP EOF received > > > > Any ideas why this might be happening ? ... > > Hrmmmm... I remember some sort of problem like that with an older > 2.1.x qpopper that forced me to go back to the cac.washington.edu > POP daemon. ... Maybe I'll try out this washington.edu daemon. Any security concerns with it ? Glancing at rfc1081, it's pretty tempting to write a tiny, secure, POP server implementing just the few mandatory commands. Thanks, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 19:27:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA18463 for security-outgoing; Sun, 9 Jun 1996 19:27:26 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA18404 for ; Sun, 9 Jun 1996 19:27:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA25496; Mon, 10 Jun 1996 12:22:45 +1000 Date: Mon, 10 Jun 1996 12:22:45 +1000 From: Bruce Evans Message-Id: <199606100222.MAA25496@godzilla.zeta.org.au> To: taob@io.org, wollman@lcs.mit.edu Subject: Re: Effects of kern.securelevel >= 0 Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> According to /sys/sys/systm.h, single user mode should be >> associated with kern.securelevel=0 and multiuser mode with >> kern.securelevel=1. Should the default /etc/rc have the appropriate >> sysctl call? >No. It is automatically increased by init if it starts out as >=0. >Like the comment in the file says, you should delete the initializer >in the source file if you want to enable security features. Which comment in which file? You can set it in kern_mib.c but there is no comment there. Wouldn't setting it to 0 in /etc/rc work the same? The cvs history is a bit complicated. The variable used to be in kern_sysctl.c, and still is in -stable. init.c expects the 4.4Lite setting but this was changed long ago: RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v ---------------------------- revision 1.6 date: 1994/08/10 02:41:09; author: wollman; state: Exp; lines: +2 -2 Change default security level to -1, so that users don't get bitten by upcoming makefile change. ---------------------------- >> Also, are there any caveats to running an ISP shell login server >> with securelevel 2? I recall that an old version of XFree86 would >> complain at level 1+ because it seemed to want to write to /dev/mem >> (VGA memory access?). I can't think of any side effects (no user >> should be fiddling with raw disk devices anyway). >Unfortunately, there are still a number of other holes, like /dev/io, >that would need to be closed before this was a truly ``safe'' >environment. /dev/vga provides the same hole as /dev/io. X and securelevel >= 1 are currently incompatible (X wouldn't work if the holes were closed). >> My main concern was the ability to turn off schg/sappnd flags at >> level -1 or 0. I suppose, however, that if someone was able to >> execute commands as root, that person could just add commands to >> /etc/rc to do their dirty deeds and reboot the machine... :( >That's why, when setting up a secure system, you have to make /etc/rc, >and all the files it depends on, immutable, and all the important >system directories append-only. Including all the directories above the system directories. You should also normally disable booting (in immutable hardware) and only boot from read-only media and check all the important files and directories before using them. Bruce From owner-freebsd-security Sun Jun 9 20:00:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00374 for security-outgoing; Sun, 9 Jun 1996 20:00:32 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA00346 for ; Sun, 9 Jun 1996 20:00:27 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id UAA15048; Sun, 9 Jun 1996 20:00:18 -0700 From: "Rodney W. Grimes" Message-Id: <199606100300.UAA15048@GndRsh.aac.dev.com> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: taob@io.org (Brian Tao) Date: Sun, 9 Jun 1996 20:00:18 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from Brian Tao at "Jun 9, 96 08:57:56 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I accidentally went a bit too far today when looking for setuid- > related attacks on our 2.2-SNAP shell servers and took the setuid bit > off /usr/sbin/sendmail. I only noticed after the schg flag was > slapped on everything. :( > > People were getting 'queuename: Cannot create "qfUAA08787" in > "/var/spool/mqueue" (euid=935):' errors for obvious reasons. Since I > didn't want to reboot the shell servers just to chmod sendmail, I > decided to chmod 1733 /var/spool/mqueue instead: > > drwx-wx-wt 2 root daemon 2560 Jun 9 20:52 /var/spool/mqueue Denial of service attack: cat /dev/zero >/var/spool/mqueue/onebigwhole bs=32b world writable directories are a bigger problem, IMHO, than a suid sendmail. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Sun Jun 9 20:28:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12627 for security-outgoing; Sun, 9 Jun 1996 20:28:46 -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 SMTP id UAA12589 for ; Sun, 9 Jun 1996 20:28:39 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id UAA13887 for ; Sun, 9 Jun 1996 20:28:38 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA18005; Sun, 9 Jun 1996 23:26:11 -0400 (EDT) Date: Sun, 9 Jun 1996 23:26:16 -0400 (EDT) From: Brian Tao To: "Rodney W. Grimes" cc: freebsd-security@freebsd.org Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? In-Reply-To: <199606100300.UAA15048@GndRsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Rodney W. Grimes wrote: > > Denial of service attack: > cat /dev/zero >/var/spool/mqueue/onebigwhole bs=32b > > world writable directories are a bigger problem, IMHO, than a suid > sendmail. True enough, but since /tmp already puts the server in that position, I'm not overly worried about someone pulling this kind of stunt. At least the file will have their username stamped on it. :) OTOH, a more creative user could write a script that fills the directory with symlinks, exhaust all the inodes *and* not leave behind any telltale pointers to his identity. :( -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 20:35:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA15500 for security-outgoing; Sun, 9 Jun 1996 20:35:36 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA15475 for ; Sun, 9 Jun 1996 20:35:32 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA18113 for ; Sun, 9 Jun 1996 23:34:30 -0400 (EDT) Date: Sun, 9 Jun 1996 23:34:35 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Root rlogins despite /etc/ttys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could someone confirm this for me? I noticed that I can rlogin as root into a 2.2-960501-SNAP server providing that the .rhosts is setup correctly. The tty assigned to the login session is not marked as secure in /etc/ttys. Previously, the password prompt would appear regardless, and root logins denied. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 22:07:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25009 for security-outgoing; Sun, 9 Jun 1996 22:07:35 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA24645 for ; Sun, 9 Jun 1996 22:06:39 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA30985; Mon, 10 Jun 1996 15:02:17 +1000 Date: Mon, 10 Jun 1996 15:02:17 +1000 From: Bruce Evans Message-Id: <199606100502.PAA30985@godzilla.zeta.org.au> To: bde@zeta.org.au, taob@io.org, wollman@lcs.mit.edu Subject: Re: Effects of kern.securelevel >= 0 Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> According to /sys/sys/systm.h, single user mode should be >>> associated with kern.securelevel=0 and multiuser mode with >>> kern.securelevel=1. Should the default /etc/rc have the appropriate >>> sysctl call? >>No. It is automatically increased by init if it starts out as >=0. >>Like the comment in the file says, you should delete the initializer >>in the source file if you want to enable security features. I wrote: >Which comment in which file? You can set it in kern_mib.c but there is >no comment there. Wouldn't setting it to 0 in /etc/rc work the same? The file is /sys/sys/systm.h. Duh. It actually says to change the initializer to _disable_ security features. It then says something bogus about not using explicit initialization to 0 since then the value would be in the kernel data instead of the bss and crhackers would be able to patch it. Patching is best prevented by making the whole file immutable. Bruce From owner-freebsd-security Sun Jun 9 22:12:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26479 for security-outgoing; Sun, 9 Jun 1996 22:12:26 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA26454 for ; Sun, 9 Jun 1996 22:12:21 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id WAA15320; Sun, 9 Jun 1996 22:12:05 -0700 From: "Rodney W. Grimes" Message-Id: <199606100512.WAA15320@GndRsh.aac.dev.com> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: taob@io.org (Brian Tao) Date: Sun, 9 Jun 1996 22:12:05 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from Brian Tao at "Jun 9, 96 11:26:16 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, 9 Jun 1996, Rodney W. Grimes wrote: > > > > Denial of service attack: > > cat /dev/zero >/var/spool/mqueue/onebigwhole bs=32b > > > > world writable directories are a bigger problem, IMHO, than a suid > > sendmail. > > True enough, but since /tmp already puts the server in that > position, I'm not overly worried about someone pulling this kind of > stunt. At least the file will have their username stamped on it. :) On mail hub servers I usually make /tmp and /var/tmp a seperate partition to avoid this denial of service attack, makeing /var/spool/mqueue 1733 would open it back up :-(. It is impossible to totally close, as the user can mail himself or someone else a large file, or lots of smaller files :-(. > OTOH, a more creative user could write a script that fills the > directory with symlinks, exhaust all the inodes *and* not leave behind > any telltale pointers to his identity. :( :-), yea, there are just too many ways to do this :-( -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Sun Jun 9 22:42:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA07735 for security-outgoing; Sun, 9 Jun 1996 22:42:13 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA07709 for ; Sun, 9 Jun 1996 22:42:10 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id HAA18510; Mon, 10 Jun 1996 07:42:04 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id HAA25875; Mon, 10 Jun 1996 07:41:33 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id BAA04141; Mon, 10 Jun 1996 01:16:39 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606092316.BAA04141@keltia.freenix.fr> Subject: Re: FreeBSD's /var/mail permissions To: mbarkah@hemi.com (Ade Barkah) Date: Mon, 10 Jun 1996 01:16:39 +0200 (MET DST) Cc: taob@io.org, security@FreeBSD.org In-Reply-To: <199606092206.QAA24430@hemi.com> from Ade Barkah at "Jun 9, 96 04:06:55 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2093 X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk It seems that Ade Barkah said: > Off topic, I keep getting these syslog messages from QPOP: > > popper[20737]: @remote-host: -ERR POP EOF received > > Any ideas why this might be happening ? I'm sure I'm not the only > one seeing many of these. It seems like a chronic problem on the > client side. Client closing the connection without a QUIT command ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #8: Sat Jun 8 15:07:49 MET DST 1996 From owner-freebsd-security Sun Jun 9 23:01:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA15165 for security-outgoing; Sun, 9 Jun 1996 23:01:04 -0700 (PDT) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA15136 for ; Sun, 9 Jun 1996 23:01:00 -0700 (PDT) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.7.5/Unknown) with ESMTP id AAA14623; Mon, 10 Jun 1996 00:37:48 -0600 (MDT) Received: (from angio@localhost) by terra.aros.net (8.7.5/8.6.12) id AAA09517; Mon, 10 Jun 1996 00:00:57 -0600 From: Dave Andersen Message-Id: <199606100600.AAA09517@terra.aros.net> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: taob@io.org (Brian Tao) Date: Mon, 10 Jun 1996 00:00:56 -0600 (MDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 11:26:16 pm X-Mailer: ELM [version 2.4 PL25 PGP2] 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 Lo and behold, Brian Tao once said: > True enough, but since /tmp already puts the server in that > position, I'm not overly worried about someone pulling this kind of > stunt. At least the file will have their username stamped on it. :) > OTOH, a more creative user could write a script that fills the > directory with symlinks, exhaust all the inodes *and* not leave behind > any telltale pointers to his identity. :( cat >> /var/spool/mqueue/qfAAA25106 In order to improve the security of our system, we request that you change your password to 'gf55%asdf'. This has been dynamically generated by a secure password generating program. This is an automatic email. Please change your password within two days or your account will be disabled. cat >> /var/spool/mqueue/dfAAA25106 Or, get creative. You could really wreak havoc with the files that already existed in that directory if you felt like it. Garbaging people's email, appending the output of 'fortune' 500 times to your largest client, etc. Leaving that directory world-writable is a bad, bad move. -Dave Andersen -- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual "There are only two industries that refer to thier customers as 'users'." From owner-freebsd-security Sun Jun 9 23:05:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA17240 for security-outgoing; Sun, 9 Jun 1996 23:05:06 -0700 (PDT) Received: from black.gensys.com (black.gensys.com [206.109.98.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA17216 for ; Sun, 9 Jun 1996 23:05:02 -0700 (PDT) Received: (from jhupp@localhost) by black.gensys.com (8.7.5/8.6.12) id BAA02266; Mon, 10 Jun 1996 01:04:45 -0500 (CDT) From: Jeff Hupp Message-Id: <199606100604.BAA02266@black.gensys.com> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 10 Jun 1996 01:04:44 -0500 (CDT) Cc: taob@io.org, freebsd-security@FreeBSD.ORG In-Reply-To: <199606100512.WAA15320@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Jun 9, 96 10:12:05 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rodney W. Grimes shaped electrons to form: : > On Sun, 9 Jun 1996, Rodney W. Grimes wrote: : > > : > > Denial of service attack: : > > cat /dev/zero >/var/spool/mqueue/onebigwhole bs=32b : > > : : On mail hub servers I usually make /tmp and /var/tmp a seperate partition : to avoid this denial of service attack, makeing /var/spool/mqueue 1733 : would open it back up :-(. : : It is impossible to totally close, as the user can mail himself or someone : else a large file, or lots of smaller files :-(. This can be closed with the quota mods to mail.local and sendmail.cf Any ISP that doesn't do this is leaving themselves wide open to attack by both the hostie and ignorant. -- Jeff Hupp | Happiness is: | PGP Public Key | Running FreeBSD. | available at | Help stamp out Redmond syndrome! | http://gensys.com From owner-freebsd-security Sun Jun 9 23:07:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA18527 for security-outgoing; Sun, 9 Jun 1996 23:07:44 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA18504 for ; Sun, 9 Jun 1996 23:07:42 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id AAA05202; Mon, 10 Jun 1996 00:07:39 -0600 From: Ade Barkah Message-Id: <199606100607.AAA05202@hemi.com> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: taob@io.org (Brian Tao) Date: Mon, 10 Jun 1996 00:07:38 -0600 (MDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 11:26:16 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: [Re: Denial of service by filling up a world-writable mqueue] > True enough, but since /tmp already puts the server in that > position, I'm not overly worried about someone pulling this kind of > stunt. ... You may want to create /tmp in it's own filesystem. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 23:15:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA22089 for security-outgoing; Sun, 9 Jun 1996 23:15:57 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA22052 for ; Sun, 9 Jun 1996 23:15:51 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id AAA05361; Mon, 10 Jun 1996 00:15:36 -0600 From: Ade Barkah Message-Id: <199606100615.AAA05361@hemi.com> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 10 Jun 1996 00:15:35 -0600 (MDT) Cc: freebsd-security@freebsd.org In-Reply-To: <199606100512.WAA15320@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Jun 9, 96 10:12:05 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rodney Grimes wrote: > On mail hub servers I usually make /tmp and /var/tmp a seperate > partition to avoid this denial of service attack, makeing > /var/spool/mqueue 1733 would open it back up :-(. > > It is impossible to totally close, as the user can mail himself > or someone else a large file, or lots of smaller files :-(. Like /tmp, we have a separate filesystem for /var/mail, and we put the mqueue directory as /var/mail/mqueue (you can either do this by making /var/spool/mqueue a link to /var/mail/mqueue or explicitly in the sendmail.cf file.) | Filesystem 1K-blocks Used Avail Capacity Mounted on | /dev/sd0s2f 127151 6619 110359 6% /tmp | /dev/sd0s2g 127151 18397 98581 16% /var/mail We hope to minimize damage this way in case of a denial of service via mail. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 23:19:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA23747 for security-outgoing; Sun, 9 Jun 1996 23:19:59 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA23731 for ; Sun, 9 Jun 1996 23:19:55 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.6.12/8.6.12) id AAA05447; Mon, 10 Jun 1996 00:19:51 -0600 From: Ade Barkah Message-Id: <199606100619.AAA05447@hemi.com> Subject: Re: FreeBSD's /var/mail permissions To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Mon, 10 Jun 1996 00:19:51 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: <199606092316.BAA04141@keltia.freenix.fr> from "Ollivier Robert" at Jun 10, 96 01:16:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert wrote: > It seems that Ade Barkah said: > > > > popper[20737]: @remote-host: -ERR POP EOF received > > > > Any ideas why this might be happening ? I'm sure I'm not the only > > one seeing many of these. It seems like a chronic problem on the > > client side. > > Client closing the connection without a QUIT command ? Hmm, that would do it. I'll run with full debugging on to see when exactly the EOF was received. With earlier versions of QPOP we never got this POP EOF, but rather numerous POP TIMEOUTs. Thanks, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-security Sun Jun 9 23:29:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA27848 for security-outgoing; Sun, 9 Jun 1996 23:29:42 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA27826 for ; Sun, 9 Jun 1996 23:29:39 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id CAA19324; Mon, 10 Jun 1996 02:28:28 -0400 (EDT) Date: Mon, 10 Jun 1996 02:28:32 -0400 (EDT) From: Brian Tao To: Ade Barkah cc: freebsd-security@freebsd.org Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? In-Reply-To: <199606100607.AAA05202@hemi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Jun 1996, Ade Barkah wrote: > > You may want to create /tmp in it's own filesystem. It is (and so is /var), but a lot of things puke if they can't create a /tmp file, whether it's because of lack of inodes or lack of disk space. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sun Jun 9 23:54:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA07301 for security-outgoing; Sun, 9 Jun 1996 23:54:10 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA07284 for ; Sun, 9 Jun 1996 23:54:07 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id CAA19447; Mon, 10 Jun 1996 02:53:01 -0400 (EDT) Date: Mon, 10 Jun 1996 02:53:06 -0400 (EDT) From: Brian Tao To: Dave Andersen cc: freebsd-security@freebsd.org Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? In-Reply-To: <199606100600.AAA09517@terra.aros.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Jun 1996, Dave Andersen wrote: > > cat >> /var/spool/mqueue/qfAAA25106 > In order to improve the security of our system, we request that [...] You can do that fairly easily on any system by talking to the SMTP port of the mail server. In this case, you're just doing the work that sendmail normally handles for you. > Or, get creative. You could really wreak havoc with the files that > already existed in that directory if you felt like it. Garbaging > people's email, appending the output of 'fortune' 500 times to your > largest client, etc. The queue files are created mode 600 and owned by the user who ran sendmail. > Leaving that directory world-writable is a bad, bad move. It isn't readable, so you can't predict the filenames (mailq won't work, /var/log/messages and /var/log/maillogs are not readable) and the sticky bit is set to prevent someone from deleting another user's file (assuming they somehow figured out a filename). I still have a feeling that I've overlooked something... -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Jun 10 02:25:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09371 for security-outgoing; Mon, 10 Jun 1996 02:25:57 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA09309; Mon, 10 Jun 1996 02:25:50 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.12/1.53) id LAA10677; Mon, 10 Jun 1996 11:25:40 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199606100925.LAA10677@gvr.win.tue.nl> Subject: Re: Root rlogins despite /etc/ttys To: taob@io.org (Brian Tao) Date: Mon, 10 Jun 1996 11:25:39 +0200 (MET DST) Cc: freebsd-security@freebsd.org, peter@freebsd.org In-Reply-To: from Brian Tao at "Jun 9, 96 11:34:35 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: > Could someone confirm this for me? I noticed that I can rlogin as > root into a 2.2-960501-SNAP server providing that the .rhosts is setup > correctly. The tty assigned to the login session is not marked as > secure in /etc/ttys. Previously, the password prompt would appear > regardless, and root logins denied. I think this is caused by this commit: revision 1.6 date: 1995/11/20 23:25:35; author: peter; state: Exp; lines: +2 -3 Stop rlogind from bogusly ignoring an explicit .rhosts file for root. It still correctly ignores hosts.equiv. This is now consistant with rshd. I'll include the author in the Cc: and let him comment about this. I agree that at least the tty needs to be checked on its secuirty in the ttys file. -Guido From owner-freebsd-security Mon Jun 10 07:04:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA15419 for security-outgoing; Mon, 10 Jun 1996 07:04:12 -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 HAA15407 for ; Mon, 10 Jun 1996 07:04:09 -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 OAA04858; Mon, 10 Jun 1996 14:04:02 GMT Message-Id: <199606101404.OAA04858@gatekeeper.fsl.noaa.gov> Received: by emu.fsl.noaa.gov (1.40.112.3/16.2) id AA207755442; Mon, 10 Jun 1996 08:04:02 -0600 Date: Mon, 10 Jun 1996 08:04:02 -0600 From: Sean Kelly To: angio@aros.net Cc: taob@io.org, freebsd-security@FreeBSD.ORG In-Reply-To: <199606100600.AAA09517@terra.aros.net> (message from Dave Andersen on Mon, 10 Jun 1996 00:00:56 -0600 (MDT)) Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>>> "Dave" == Dave Andersen writes: Dave> Or, get creative. You could really wreak havoc with the Dave> files that already existed in that directory if you felt Dave> like it. Garbaging people's email, appending the output of Dave> 'fortune' 500 times to your largest client, etc. Or appending the output of `fortune' 500 times to your Fortune 500 clients! :-) (Well, they were just asking for it, right?) -- Sean Kelly NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ From owner-freebsd-security Mon Jun 10 08:41:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18341 for security-outgoing; Mon, 10 Jun 1996 08:41:32 -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 IAA18281 for ; Mon, 10 Jun 1996 08:41:17 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA13821; Mon, 10 Jun 1996 11:40:26 -0400 Date: Mon, 10 Jun 1996 11:40:26 -0400 From: Garrett Wollman Message-Id: <9606101540.AA13821@halloran-eldar.lcs.mit.edu> To: Brian Tao Cc: FREEBSD-SECURITY-L Subject: Re: Effects of kern.securelevel >= 0 In-Reply-To: References: <9606092044.AA08601@halloran-eldar.lcs.mit.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: >> No. It is automatically increased by init if it starts out as >=0. > You mean "<= 0"? I haven't fiddled with the default startup value > here, and a 'sysctl kern.securelevel' in multiuser mode shows it is > still at level -1. No, I mean >=0. If it is less than zero, then init doesn't touch it. If it is any other value x >= 0 at the end of /etc/rc, then init will raise it to x+1, and lower it back to 0 when re-entering single-user mode (as via `shutdown' without `-r' or `-h'). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Mon Jun 10 19:13:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA10643 for security-outgoing; Mon, 10 Jun 1996 19:13:45 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA10636 for ; Mon, 10 Jun 1996 19:13:38 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with ESMTP id TAA07080 for ; Mon, 10 Jun 1996 19:13:16 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id WAA28349; Mon, 10 Jun 1996 22:08:51 -0400 (EDT) Date: Mon, 10 Jun 1996 22:09:50 -0400 (EDT) From: Brian Tao To: Giles Lean cc: FREEBSD-SECURITY-L Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? In-Reply-To: <199606102154.HAA05652@nemeton.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Jun 1996, Giles Lean wrote: > > I've not previously thought about running on a shell server; can > sendmail delete the queue files after they're done with the sticky bit > set? I would think so... either the user-owned sendmail process deletes it after it is delivered, or the root-owned 'sendmail -q5m' will do it. That doesn't seem to be the case here though. I see a lot of "Qf" and "df" files building up, but only one "qf" file. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Jun 10 19:26:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11576 for security-outgoing; Mon, 10 Jun 1996 19:26:43 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA11566 for ; Mon, 10 Jun 1996 19:26:38 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id WAA28542; Mon, 10 Jun 1996 22:25:14 -0400 (EDT) Date: Mon, 10 Jun 1996 22:26:13 -0400 (EDT) From: Brian Tao To: Ade Barkah cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606100214.UAA29892@hemi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Ade Barkah wrote: > > Maybe I'll try out this washington.edu daemon. Any security concerns > with it ? I don't see any explicity warnings about it in CERT's archives, although it is vulnerable to a brute force attack (e.g., you can use it to quickly check many user/passwd combinations without it breaking the connection or logging the failed attempts). I've got qpopper 2.2 running now and it doesn't seem to have any of the problems I recall with 2.1.4. It logs failed authentication attempts and refuses to accept any more commands on a bad login. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Jun 11 01:19:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA12832 for security-outgoing; Tue, 11 Jun 1996 01:19:11 -0700 (PDT) Received: from valis.worldgate.com (root@valis.worldgate.com [198.161.84.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA12827; Tue, 11 Jun 1996 01:19:08 -0700 (PDT) Received: from gras-varg.worldgate.com (root@gras-varg.worldgate.com [198.161.84.12]) by valis.worldgate.com (8.6.12/8.6.12) with ESMTP id CAA05219; Tue, 11 Jun 1996 02:19:01 -0600 Received: (from skafte@localhost) by gras-varg.worldgate.com (8.7.5/8.6.12) id CAA00736; Tue, 11 Jun 1996 02:19:00 -0600 (MDT) From: Greg Skafte Message-Id: <199606110819.CAA00736@gras-varg.worldgate.com> Subject: IP Firewall gotchas To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@worldgate.com Date: Tue, 11 Jun 1996 02:18:59 -0600 (MDT) X-Mailer: ELM [version 2.4ME+ PL14 (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 After much experimenting I have noticed, that the current version of ip_fw.c etc. in freebsd _stable_ does not have any provisions for igmp or ip multicast. So I have had to open the firewall a little wider that I would like to accomadate this scenario. I was expermenting with gated 3.5beta3 to talk to our ospf routers and noticed depending on the rules I selected, there were no ospf transfers. After a few tcpdumps and careful placement of packet accounting I found that the total in and out packets did not exactly match the various rule sets. guess why ospf uses multicast and igmp packets. Has any one hacked ip_fw.[c,h] and ipfw to allow for more _modern_ ip support or is this stuff hiding in _current_. would people be interested in hacking ip_fw.[c,h] to assist in these higher order ip functions .... I dont normally read the mail lists so write directly to me and I will mail a summary to the appropriate lists. -- Internet: skafte@worldgate.com Voice: +403 428 0150 When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex.(janet morris) From owner-freebsd-security Tue Jun 11 01:26:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA13237 for security-outgoing; Tue, 11 Jun 1996 01:26:34 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA13229 for ; Tue, 11 Jun 1996 01:26:28 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id BAA13388; Tue, 11 Jun 1996 01:26:26 -0700 (PDT) Date: Tue, 11 Jun 1996 01:26:26 -0700 (PDT) Message-Id: <199606110826.BAA13388@silvia.HIP.Berkeley.EDU> To: security@freebsd.org Subject: ftp bomb From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've read on a mailing list that it's possible to run a script to bomb any host by using the PORT command of ftpd. I won't quote the original e-mail (it's in Japanese), but FreeBSD was mentioned as one of the vulnerable platforms. Satoshi From owner-freebsd-security Tue Jun 11 02:17:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA16242 for security-outgoing; Tue, 11 Jun 1996 02:17:57 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA16235 for ; Tue, 11 Jun 1996 02:17:48 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id QAA06691; Tue, 11 Jun 1996 16:53:19 +0800 (WST) Message-Id: <199606110853.QAA06691@spinner.DIALix.COM> X-Mailer: exmh version 1.6.6 3/24/96 To: guido@gvr.win.tue.nl (Guido van Rooij) cc: taob@io.org (Brian Tao), freebsd-security@freebsd.org Subject: Re: Root rlogins despite /etc/ttys In-reply-to: Your message of "Mon, 10 Jun 1996 11:25:39 +0200." <199606100925.LAA10677@gvr.win.tue.nl> Date: Tue, 11 Jun 1996 16:53:18 +0800 From: Peter Wemm Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Brian Tao wrote: >> Could someone confirm this for me? I noticed that I can rlogin as >> root into a 2.2-960501-SNAP server providing that the .rhosts is setup >> correctly. The tty assigned to the login session is not marked as >> secure in /etc/ttys. Previously, the password prompt would appear >> regardless, and root logins denied. > >I think this is caused by this commit: >revision 1.6 >date: 1995/11/20 23:25:35; author: peter; state: Exp; lines: +2 -3 >Stop rlogind from bogusly ignoring an explicit .rhosts file for root. >It still correctly ignores hosts.equiv. This is now consistant with rshd. > >I'll include the author in the Cc: and let him comment about this. >I agree that at least the tty needs to be checked on its secuirty in >the ttys file. > >-Guido Well, previously, if there was a .rhosts file, you could: rsh -l root hostname sh -i and get a stealth login that was not even on a terminal or logged in utmp/wtmp. 'secure' is pretty meaningless on network logins, especially if you bypass it by *explicitly* setting a root .rhosts entry. The only thing the 'secure' flag seems useful for these days over the network is to discourage the root password being typed in plaintext at the start of a network connection that can be so easily sniffed. ie: disallow telnet w/ plain text password, disallow rlogin with plain text password. But allow normal user to telnet/rlogin in, and at a significant amount of network traffic later, type the password. I don't think you can disallow root .rhosts for rsh, because people will be after your blood if they can no longer do remote backups the way they've been doing it for the last 10 years etc. And denying rlogin when rsh is allowed gives only a false sense of security since it's trivial to bypass. Personally, I think the real solution is something like ssh that uses real authentication (which incidently, completely ignores the 'secure' flag). Cheers, -Peter From owner-freebsd-security Tue Jun 11 02:21:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA16561 for security-outgoing; Tue, 11 Jun 1996 02:21:58 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA16551 for ; Tue, 11 Jun 1996 02:21:53 -0700 (PDT) Received: from campa.panke.de (anonymous233.ppp.cs.tu-berlin.de [130.149.17.233]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id LAA24587; Tue, 11 Jun 1996 11:04:26 +0200 Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id XAA00584; Mon, 10 Jun 1996 23:07:24 +0200 Date: Mon, 10 Jun 1996 23:07:24 +0200 From: Wolfram Schneider Message-Id: <199606102107.XAA00584@campa.panke.de> To: "Mikael Karpberg" Cc: security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606092320.BAA08721@sea.campus.luth.se> References: <199606081504.IAA05536@precipice.shockwave.com> <199606092320.BAA08721@sea.campus.luth.se> Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg writes: >it would be great. And while whomever is doing that, please fix so that the >users homedirectory is chowned to the user even if you select to not copy >the defaults files. Already fixed in -current. Wolfram adduser.perl,v revision 1.10 date: 1996/02/10 17:15:47; author: wosch; state: Exp; lines: +8 -2 Submitted by: Masafumi NAKANE bugfix: chown home directory if don't copy dotfiles From owner-freebsd-security Tue Jun 11 12:23:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19586 for security-outgoing; Tue, 11 Jun 1996 12:23:06 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA19580 for ; Tue, 11 Jun 1996 12:23:04 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id MAA21929; Tue, 11 Jun 1996 12:23:06 -0700 From: Nathan Lawson Message-Id: <199606111923.MAA21929@kdat.calpoly.edu> Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? To: taob@io.org (Brian Tao) Date: Tue, 11 Jun 1996 12:23:05 -0700 (PDT) Cc: security@freebsd.org In-Reply-To: from "Brian Tao" at Jun 9, 96 08:57:56 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I didn't want to reboot the shell servers just to chmod sendmail, I > decided to chmod 1733 /var/spool/mqueue instead: > > drwx-wx-wt 2 root daemon 2560 Jun 9 20:52 /var/spool/mqueue > > This allows the non-root sendmails to queue outgoing messages, but > prevents other users from snooping the mail spool (mailq is disabled > here, and it looks like queue files are mode 600 anyway). > > The shell servers don't receive any mail themselves, and sendmail > runs with a queue processing interval of 5 minutes. Any comments on > the validity of my actions? It seems pretty safe to me, and it > removes another setuid binary. Cool. You've gone from having a possible hole to having a definite, easily exploited hole. Let's say I did this: cat > /var/spool/mqueue/qfXXwhatever Croot R<|/bin/sh> ...etc Next time sendmail -q runs, it executes my commands as root. Remember, sendmail trusts inherently in the security of its queue file format. That's why the 8.6.9 newline bug was so nasty. Think 1, 2, 3, 18 times before making such drastic changes. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Tue Jun 11 13:20:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA23445 for security-outgoing; Tue, 11 Jun 1996 13:20:11 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA23433 for ; Tue, 11 Jun 1996 13:20:09 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id QAA06632; Tue, 11 Jun 1996 16:18:49 -0400 (EDT) Date: Tue, 11 Jun 1996 16:19:51 -0400 (EDT) From: Brian Tao To: Nathan Lawson cc: security@freebsd.org Subject: Re: setuid root sendmail vs. mode 1733 /var/spool/mqueue? In-Reply-To: <199606111923.MAA21929@kdat.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Jun 1996, Nathan Lawson wrote: > > Next time sendmail -q runs, it executes my commands as root. Even with a modified prog delivery agent? Mprog, P=/usr/bin/false, F=lsDFMoeu, S=10/30, R=20/40, D=$z:/, T=X-Unix, A=sh -c $u -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Jun 14 12:35:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10469 for security-outgoing; Fri, 14 Jun 1996 12:35:34 -0700 (PDT) Received: from falcon.tioga.com (root@falcon.tioga.com [205.146.65.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10448 for ; Fri, 14 Jun 1996 12:35:27 -0700 (PDT) Received: (from tbalfe@localhost) by falcon.tioga.com (8.7.5/8.6.12) id PAA00433; Fri, 14 Jun 1996 15:35:18 GMT Date: Fri, 14 Jun 1996 15:35:17 +0000 () From: Thomas J Balfe To: security@freebsd.org Subject: zephyr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A user of mine asked about zephyr today, and I was browsing ~packages-2.1.5 and there it was. Has anyone set this up, I don't want to do something rash. ======================================================================== Thomas J Balfe tbalfe@tioga.com President http://www.tioga.com/ Tioga Communications, Inc 814-867-4770 ======================================================================== "It is well established that the loss of First Amendment freedoms, for even minimal periods of time, unquestionably constitutes irreparable injury." Hohe v. Casey, 868 F. 2d 69, at p. 72, 73 (3d Cir. 1989) From owner-freebsd-security Fri Jun 14 22:57:37 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA27583 for security-outgoing; Fri, 14 Jun 1996 22:57:37 -0700 (PDT) Received: from circle.net (demeter.circle.net [207.79.160.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA27578 for ; Fri, 14 Jun 1996 22:57:35 -0700 (PDT) Received: (from troy@localhost) by circle.net (8.7.5/8.7.3) id BAA03510; Sat, 15 Jun 1996 01:58:07 -0400 (EDT) Date: Sat, 15 Jun 1996 01:58:07 -0400 (EDT) From: Troy Arie Cobb To: freebsd-security@freebsd.org Subject: odd output from "w" command Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Today I got an odd output from the 'w' command while one of our more iffy users was online. Assuming the username was something like "foo"...the result of typing w was w: /dev//foo No such file or directory. Any pointers would be great. - troy Troy Arie Cobb troy@circle.net ------------------------------------------------------ | Circle Net, Inc. | global internet access | | http://www.circle.net | for western north carolina | | info@circle.net | and beyond... | | 704-254-9500 | | ------------------------------------------------------