From owner-freebsd-security Sun Oct 13 11:46:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00329 for security-outgoing; Sun, 13 Oct 1996 11:46:14 -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 LAA00324 for ; Sun, 13 Oct 1996 11:46:12 -0700 (PDT) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13]) by cs.pdx.edu (8.7.5/CATastrophe-2/10/96-P) with ESMTP id LAA16661; Sun, 13 Oct 1996 11:46:11 -0700 (PDT) for Received: from localhost (jrb@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.7.5/CATastrophe-9/18/94-C) with ESMTP id LAA24537; Sun, 13 Oct 1996 11:46:09 -0700 (PDT) Message-Id: <199610131846.LAA24537@sirius.cs.pdx.edu> To: fyeung@fyeung8.netific.com (Francis Yeung) cc: security@freebsd.org Subject: Re: IPSec on FreeBSD In-reply-to: Your message of "Sat, 12 Oct 1996 10:59:33 PDT." <9610121759.AA18441@fyeung8.netific.com> Date: Sun, 13 Oct 1996 11:46:09 -0700 From: Jim Binkley Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Your message <9610121759.AA18441@fyeung8.netific.com>: > >Greetings, > > Has anyone ported the NetBSD's IPSec code to FreeBSD ? > > Thx. > > Fran We have taken the code from last june and very painfully ported ONLY the IPSEC part into FreeBSD 2.1R. It is non-trivial to do this (understatement of the century). The NRL release wants you to make both their version of IPv6/IPSEC at the same time, and we don't want or care about IPv6. So what we have is IPv4/IPSEC. (The IPv6 stuff requires even more munges to IPv4, than just IPSEC/IPv4). Also their ipsec stuff is socket based. We have done minimal testing of the socket tied-in code and are beginning to test it in a bigger way. We are also tying the NRL ipsec stuff to routing as that is what we really want (VPNs). If you have any interest, I suggest private email. regards, Jim Binkley jrb@cs.pdx.edu From owner-freebsd-security Sun Oct 13 15:19:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA08711 for security-outgoing; Sun, 13 Oct 1996 15:19:54 -0700 (PDT) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA08685 for ; Sun, 13 Oct 1996 15:19:23 -0700 (PDT) Received: from localhost (davidn@localhost) by sdev.usn.blaze.net.au (8.7.6/8.6.9) with SMTP id IAA22952; Mon, 14 Oct 1996 08:16:24 +1000 (EST) Date: Mon, 14 Oct 1996 08:16:23 +1000 (EST) From: David Nugent Reply-To: davidn@blaze.net.au To: Peter Childs cc: Antonio Navarro Navarro , freebsd-security@FreeBSD.org Subject: Re: Restricted access via FTP In-Reply-To: <199610101916.EAA01749@al.imforei.apana.org.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 Fri, 11 Oct 1996, Peter Childs wrote: > I suggest either finding these, or just modifiying wu-ftpd yourself > so that it "chroot"'s into users home directories when they log in > with ftp. You'll need to remember that if they do chroot then they > require accessable copies of "ls" and stuff like that. > > Perhaps you should make it so that it "chroot"'s to /home and then > have a /home/bin with static binaries users might require for > ftp (like ls) I recall seeing some wu-ftp patches that implemented built-in ls, which would seem to get around this shortfall and also offered a minor boost to performance on very loaded servers. The only thing the user loses on in using this with no special copying of files (which has its own security risks attached - wonder who would place a nice bomb in ~username/bin/ls some time?) would be the gzip/tar capability in wu-ftp. I doubt many would really miss it for non-anon use. Sorry I can't be more specific about the location of the patches, but at the time I didn't need them and didn't take any special note. David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-791-9547 Data/BBS +61-3-792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn From owner-freebsd-security Mon Oct 14 11:17:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14682 for security-outgoing; Mon, 14 Oct 1996 11:17:38 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA14673; Mon, 14 Oct 1996 11:17:33 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id MAA12854; Mon, 14 Oct 1996 12:17:32 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id MAA04744; Mon, 14 Oct 1996 12:14:56 -0600 (MDT) Date: Mon, 14 Oct 1996 12:14:55 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: security-officer@freebsd.org, freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <199610141152.EAA23237@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 14 Oct 1996 rkozak@bdk.lublin.pl wrote: > > >Number: 1805 > >Category: bin > >Synopsis: Bug in ftpd > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Mon Oct 14 05:00:01 PDT 1996 > >Last-Modified: > >Originator: Robert Kozak > >Organization: > BDK w Lublinie S.A. > >Release: FreeBSD 2.1.5-RELEASE > >Environment: > FreeBSD celebris1.bdk.lublin.pl 2.1.5-RELEASE FreeBSD 2.1.5-RELEASE #0: Thu Sep > 5 13:21:39 MET DST 1996 root@celebris1.bdk.lublin.pl:/usr/src/sys/compile/ > RKKERNEL i386 > >Description: > While user is connected to server via ftp, the process ftpd is owned > by this user. When ftpd is abnormally termineted (e.g. kill -11 ) > the memory image of this process is writed to file ftpd.core in home dir. > This file contain encrypted passwords all users on this machine. > > > >How-To-Repeat: > 1. ftp localhost > name: username > password: **** > 2. On second terminal: > a) ps -ax | grep localhost > b) kill -11 > c) strings ~/ftpd.core | less (you will see all encrypted passwords). > > >Fix: > > >Audit-Trail: > >Unformatted: > That isn't nice. I don't think it will contain the passwords of all the users, just a certain subset of them. This also a problem with older versions of wuftpd, but the latest beta seems to be fine, although I'm not sure if that is just a fluke or by design. There are several possible fixes, but for those that need a temporary fix ASAP, a workaround follows. There should be no security problems with this, but there could be something I'm missing. Create a script. I'll assume it is /usr/local/libexec/ftpd.wrapper. In it, put the following: ------- #!/bin/sh ulimit -c 0 exec /usr/libexec/ftpd $* ------- where /usr/libexec/ftpd is the path to your old ftp daemon. Modify /etc/inetd.conf and replace /usr/libexec/ftpd with /usr/local/libexec/ftpd.wrapper. What this does is prevent the process from core dumping, therefore eliminating the problem. A more permanent fix to the source may be something along the lines of the below patch (against RELENG_2_1_5_RELEASE), but there should be an official fix out in the next little bit: *** /usr/src/libexec/ftpd/ftpd.c Mon Mar 18 04:10:16 1996 --- ftpd.c Mon Oct 14 12:07:21 1996 *************** *** 47,55 **** --- 47,58 ---- * FTP server. */ #include + #include + #include #include #include #include + #include #include #include *************** *** 219,227 **** --- 222,232 ---- int addrlen, ch, on = 1, tos; char *cp, line[LINE_MAX]; FILE *fd; + struct rlimit rlim; tzset(); /* in case no timezone database in ~ftp */ + /* * LOG_NDELAY sets up the logging connection immediately, * necessary for anonymous ftp's that chroot and can't do it later. *************** *** 232,237 **** --- 237,253 ---- syslog(LOG_ERR, "getpeername (%s): %m",argv[0]); exit(1); } + + /* + * prevent ftpd from dumping core; necessary to prevent a user + * from getting a core file with privileged information in + */ + rlim.rlim_cur = rlim.rlim_max = 0; + if (setrlimit(RLIMIT_CORE, &rlim) != 0) { + syslog(LOG_ERR, "setrlimit(RLIMIT_CORE, &rlim) failed"); + exit(1); + } + #ifdef SKEY strcpy(addr_string, inet_ntoa(his_addr.sin_addr)); #endif From owner-freebsd-security Mon Oct 14 14:00:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25286 for security-outgoing; Mon, 14 Oct 1996 14:00:42 -0700 (PDT) Received: from gvr.win.tue.nl (gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA25281; Mon, 14 Oct 1996 14:00:34 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id WAA02649; Mon, 14 Oct 1996 22:59:19 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199610142059.WAA02649@gvr.win.tue.nl> Subject: Re: bin/1805: Bug in ftpd To: marcs@znep.com (Marc Slemko) Date: Mon, 14 Oct 1996 22:59:19 +0200 (MET DST) Cc: security-officer@freebsd.org, freebsd-security@freebsd.org In-Reply-To: from Marc Slemko at "Oct 14, 96 12:14:55 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 Marc Slemko wrote: > A more permanent fix to the source may be something along the lines of the > below patch (against RELENG_2_1_5_RELEASE), but there should be an > official fix out in the next little bit: > I'm not really happy with this fix as well, but it's better than nothing., The reason being that if ftp wants to dump core, it should dump core. If you prohibit this you'll never be able to debug any problems after somethuing went wrong. What should be done is make sure the buffers containing the sensitive info are cleared as soon as the info has been used. The same problem could show up with any other suid root program that reads the password databases. (if that is indeed the happening. It might also be that just the users password string is dumped only.) I'll investigate things tomorrow evening. -Guido From owner-freebsd-security Mon Oct 14 14:58:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA28278 for security-outgoing; Mon, 14 Oct 1996 14:58:47 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA28270 for ; Mon, 14 Oct 1996 14:58:40 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA24231; Mon, 14 Oct 1996 15:57:27 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA05844; Mon, 14 Oct 1996 15:52:19 -0600 (MDT) Date: Mon, 14 Oct 1996 15:52:18 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Guido van Rooij cc: freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <199610142059.WAA02649@gvr.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 14 Oct 1996, Guido van Rooij wrote: > Marc Slemko wrote: > > A more permanent fix to the source may be something along the lines of the > > below patch (against RELENG_2_1_5_RELEASE), but there should be an > > official fix out in the next little bit: > > > > I'm not really happy with this fix as well, but it's better than nothing., > The reason being that if ftp wants to dump core, it should dump core. > If you prohibit this you'll never be able to debug any problems after > somethuing went wrong. What should be done is make sure the buffers containing > the sensitive info are cleared as soon as the info has been used. > The same problem could show up with any other suid root program that reads > the password databases. (if that is indeed the happening. It might also be > that just the users password string is dumped only.) I agree that ftpd should be able to dump core if it wants to, but don't see an obvious solution that can be implemented in the ftpd code. From a quick look at ftpd.c, it seems to be doing the logical thing and simply calling getpwnam(3) to get the user info. This means that either the memory would have to be cleared by getpwnam, or some horribly inefficient hack would have to be put in ftpd. I haven't investigated this too far yet, but the idea of having the getpwent code clear each buffer it uses before freeing it may be practical and doesn't look too complex. That shouldn't create too much overhead and could certainly benefit more than ftpd. There is definitely more than one user's password string being dumped. The FreeBSD boxes I have handy right now don't have many users, so I have only seen half a dozen or so (ie. the number of users) but on the BSD/OS box it was definitely more than a dozen passwords. Not a deadly flaw, especially since people should act as if the contents of their shadow password files are world readable anyway, but potentially quite serious if the wrong accounts are in there and the admin isn't running anything like crack. This is not just a problem with FreeBSD, but also BSD/OS 2.0.1 and possibly AIX (the box I tested on showed the problem of core dumping, but is using AFS so authentication works differently). NetBSD and OpenBSD are likely affected too. I haven't tested this on a -current box, but I am assuming the code will be the same since neither ftpd or the getpwent library have changed much. SunOS 4.x and 5.x don't seem vulnerable. It is also present in older (ie. before the current beta versions) releases of wuftpd. In current versions of wuftpd, it is avoided by having signal handlers installed and having the signal handler simply call exit(1). In older versions of wuftpd, the signal handlers were there but they called abort() so it dumped core anyway. If a solution within ftpd is required, I would suggest that either a compile time define (eg. DEBUG) to enable dumping core or a command line flag, with appropriate warnings, to allow dumping core may be a compromise between not dumping core and allowing debugging. It is arguable if it is a bug in ftpd or in the getpwent routines, but I would be tempted to say both. From owner-freebsd-security Mon Oct 14 15:44:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02421 for security-outgoing; Mon, 14 Oct 1996 15:44:51 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA02401 for ; Mon, 14 Oct 1996 15:44:43 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.7.5/8.7.3) id AAA00477; Tue, 15 Oct 1996 00:40:49 +0200 (MET DST) To: Marc Slemko Cc: Guido van Rooij , freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd References: Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 15 Oct 1996 00:40:46 +0200 In-Reply-To: Marc Slemko's message of Mon, 14 Oct 1996 15:52:18 -0600 (MDT) Message-ID: <5lvicd6ufk.fsf@assaris.sics.se> Lines: 53 X-Mailer: Gnus v5.2.40/Emacs 19.34 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Marc Slemko writes: > On Mon, 14 Oct 1996, Guido van Rooij wrote: > > > Marc Slemko wrote: > > > A more permanent fix to the source may be something along the lines of the > > > below patch (against RELENG_2_1_5_RELEASE), but there should be an > > > official fix out in the next little bit: > > > > > > > the sensitive info are cleared as soon as the info has been used. > > The same problem could show up with any other suid root program that reads > > the password databases. (if that is indeed the happening. It might also be > > that just the users password string is dumped only.) > > I agree that ftpd should be able to dump core if it wants to, but don't > see an obvious solution that can be implemented in the ftpd code. From a > quick look at ftpd.c, it seems to be doing the logical thing and simply > calling getpwnam(3) to get the user info. This means that either the > memory would have to be cleared by getpwnam, or some horribly inefficient > hack would have to be put in ftpd. I think this is a more general problem. And sometimes it's even worse. Look at login: /* Discard permissions last so can't get killed and drop core. */ if (rootlogin) (void) setuid(0); else (void) setuid(pwd->pw_uid); if (changepass) { int res; if ((res=system(_PATH_CHPASS))) sleepexit(1); } execlp(pwd->pw_shell, tbuf, 0); err(1, "%s", pwd->pw_shell); } After the setuid, I will be able to make it dump core, or even better use `ptrace' and then login will still have the file descriptor pointing to /etc/spwd.db open and I can make it read the complete shadow file. > I haven't investigated this too far yet, but the idea of having the > getpwent code clear each buffer it uses before freeing it may be practical > and doesn't look too complex. That shouldn't create too much overhead and > could certainly benefit more than ftpd. Why don't make endpwent clear the area and make ftpd & c:o call it? /assar From owner-freebsd-security Mon Oct 14 16:06:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA03994 for security-outgoing; Mon, 14 Oct 1996 16:06:31 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA03989 for ; Mon, 14 Oct 1996 16:06:29 -0700 (PDT) Received: from fubar.cl.msu.edu (fubar.cl.msu.edu [35.8.1.18]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id QAA22045 for ; Mon, 14 Oct 1996 16:06:08 -0700 (PDT) Received: (from evans@localhost) by fubar.cl.msu.edu (8.6.12/8.6.12) id TAA01206; Mon, 14 Oct 1996 19:01:59 -0400 Date: Mon, 14 Oct 1996 19:01:59 -0400 From: Jeff Evans Message-Id: <199610142301.TAA01206@fubar.cl.msu.edu> To: freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc Slemko wrote: > A more permanent fix to the source may be something along the lines of the > below patch (against RELENG_2_1_5_RELEASE), but there should be an > official fix out in the next little bit: > > >I'm not really happy with this fix as well, but it's better than nothing., >The reason being that if ftp wants to dump core, it should dump core. >If you prohibit this you'll never be able to debug any problems after >somethuing went wrong. What should be done is make sure the buffers containing >the sensitive info are cleared as soon as the info has been used. >The same problem could show up with any other suid root program that reads >the password databases. (if that is indeed the happening. It might also be >that just the users password string is dumped only.) > >I'll investigate things tomorrow evening. > >-Guido At least on a FreeBSD 2.1.0-RELEASE #0 running wu-ftp version wu-2.4(3), an ftpd core file shows about 33 encrypted entries in a password file of 667. I didn't use the exact work around posted, but the following seemed to do the job: #!/usr/local/bin/tcsh limit -h coredumpsize 0 exec /usr/local/ftpd/libexec/ftpd $argv entry from /etc/inetd.conf: ftp stream tcp nowait root /usr/local/ftpd/libexec/ftpd.wrapper ftpd I attempted to cause a core file using Qualicomm's qpopper2.2, but couldn't get it to leave a core file (possibly due to insufficient quota or the working directory being /). Are there any other programs that use getpwnam or the like that run as root and then switch to a user after? Jeff -- -------------------------------------------------------------------------- Jeff Evans - evans@msu.edu - http://clunix.cl.msu.edu/~evans -------------------------------------------------------------------------- From owner-freebsd-security Mon Oct 14 17:39:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA09640 for security-outgoing; Mon, 14 Oct 1996 17:39:33 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA09630 for ; Mon, 14 Oct 1996 17:39:28 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id SAA02915; Mon, 14 Oct 1996 18:38:33 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA06675; Mon, 14 Oct 1996 18:37:26 -0600 (MDT) Date: Mon, 14 Oct 1996 18:37:25 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Assar Westerlund cc: Guido van Rooij , freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <5lvicd6ufk.fsf@assaris.sics.se> 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 15 Oct 1996, Assar Westerlund wrote: > > I agree that ftpd should be able to dump core if it wants to, but don't > > see an obvious solution that can be implemented in the ftpd code. From a > > quick look at ftpd.c, it seems to be doing the logical thing and simply > > calling getpwnam(3) to get the user info. This means that either the > > memory would have to be cleared by getpwnam, or some horribly inefficient > > hack would have to be put in ftpd. > > I think this is a more general problem. And sometimes it's even > worse. Look at login: > > /* Discard permissions last so can't get killed and drop core. */ > if (rootlogin) > (void) setuid(0); > else > (void) setuid(pwd->pw_uid); > > if (changepass) { > int res; > if ((res=system(_PATH_CHPASS))) > sleepexit(1); > } > > execlp(pwd->pw_shell, tbuf, 0); > err(1, "%s", pwd->pw_shell); > } > > After the setuid, I will be able to make it dump core, or even better > use `ptrace' and then login will still have the file descriptor > pointing to /etc/spwd.db open and I can make it read the complete > shadow file. You are right. I just checked, and I can make login dump core in the same way and reveal similar information. Haven't tried stealing the file descriptor since that takes effort, but it certainly looks like it could be possible. > > > I haven't investigated this too far yet, but the idea of having the > > getpwent code clear each buffer it uses before freeing it may be practical > > and doesn't look too complex. That shouldn't create too much overhead and > > could certainly benefit more than ftpd. > > Why don't make endpwent clear the area and make ftpd & c:o call it? That sounds like the best idea. The problem is more widespread than I realized. Note that getpwent calls a bunch of NIS routines; they have to be checked to see if they leave anything messy around. I think some of the buffers we want to zero are from the DB routines, which could make it even messier if the memory is allocated inside the DB routines and not as a structure in getpwent. What other information could ftpd (or login, etc.) have around other that information from the getpwent that we don't want non-root users to see? I still think that it is the responsibility of any process which starts running as root then drops to the user to be sure not to leave any potentially bad data in memory. In practice, however, that isn't always practical, and I think the getpwent routines are of a nature that they should be designed to not leave anything dangerous behind after an endpwent. So it looks like endpwent needs to be fixed up to clean up better after itself and all programs that start as root and end up setuid to a user need to be checked to be sure that they call endpwent after any getpwent routines they call and before they setuid to the user. From owner-freebsd-security Mon Oct 14 18:01:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10907 for security-outgoing; Mon, 14 Oct 1996 18:01:41 -0700 (PDT) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10902; Mon, 14 Oct 1996 18:01:38 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id SAA08402; Mon, 14 Oct 1996 18:01:15 -0700 (PDT) From: Don Lewis Message-Id: <199610150101.SAA08402@salsa.gv.ssi1.com> Date: Mon, 14 Oct 1996 18:01:15 -0700 In-Reply-To: guido@gvr.win.tue.nl (Guido van Rooij) "Re: bin/1805: Bug in ftpd" (Oct 14, 10:59pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: guido@gvr.win.tue.nl (Guido van Rooij), marcs@znep.com (Marc Slemko) Subject: Re: bin/1805: Bug in ftpd Cc: security-officer@freebsd.org, freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Oct 14, 10:59pm, Guido van Rooij wrote: } Subject: Re: bin/1805: Bug in ftpd } Marc Slemko wrote: } > A more permanent fix to the source may be something along the lines of the } > below patch (against RELENG_2_1_5_RELEASE), but there should be an } > official fix out in the next little bit: } > } } I'm not really happy with this fix as well, but it's better than nothing., But not much ... There's nothing stopping someone to attaching to the process with the debugger and dumping out the locations in memory that contain the secret stuff. } The reason being that if ftp wants to dump core, it should dump core. } If you prohibit this you'll never be able to debug any problems after } somethuing went wrong. What should be done is make sure the buffers containing } the sensitive info are cleared as soon as the info has been used. Yes, it is important that any copies of this information are destroyed before the process changes its uid. --- Truck From owner-freebsd-security Mon Oct 14 18:02:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10944 for security-outgoing; Mon, 14 Oct 1996 18:02:53 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-35.rdcy01.pacbell.net [206.170.5.35]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10939; Mon, 14 Oct 1996 18:02:49 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.6/8.7.3) with ESMTP id SAA07582; Mon, 14 Oct 1996 18:02:07 -0700 (PDT) Message-Id: <199610150102.SAA07582@precipice.shockwave.com> To: guido@gvr.win.tue.nl (Guido van Rooij) cc: marcs@znep.com (Marc Slemko), security-officer@freebsd.org, freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-reply-to: Your message of "Mon, 14 Oct 1996 22:59:19 +0200." <199610142059.WAA02649@gvr.win.tue.nl> Date: Mon, 14 Oct 1996 18:02:07 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At best, this needs to be on a flag, but the better choice in total would be to clear all data structures when the library calls return (when using getpwbyname() and bzero the data structures and context for the whole mess if an endpwent() is done. This is not a ftpd bug, and I think we shouldn't touch ftpd to fix it. From: guido@gvr.win.tue.nl (Guido van Rooij) Subject: Re: bin/1805: Bug in ftpd Marc Slemko wrote: > A more permanent fix to the source may be something along the lines of the > below patch (against RELENG_2_1_5_RELEASE), but there should be an > official fix out in the next little bit: > I'm not really happy with this fix as well, but it's better than nothing., The reason being that if ftp wants to dump core, it should dump core. If you prohibit this you'll never be able to debug any problems after somethuing went wrong. What should be done is make sure the buffers containin >>g the sensitive info are cleared as soon as the info has been used. The same problem could show up with any other suid root program that reads the password databases. (if that is indeed the happening. It might also be that just the users password string is dumped only.) I'll investigate things tomorrow evening. -Guido From owner-freebsd-security Mon Oct 14 19:14:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA15591 for security-outgoing; Mon, 14 Oct 1996 19:14:38 -0700 (PDT) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA15586 for ; Mon, 14 Oct 1996 19:14:36 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA08800; Mon, 14 Oct 1996 19:13:49 -0700 (PDT) From: Don Lewis Message-Id: <199610150213.TAA08800@salsa.gv.ssi1.com> Date: Mon, 14 Oct 1996 19:13:49 -0700 In-Reply-To: Marc Slemko "Re: bin/1805: Bug in ftpd" (Oct 14, 6:37pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Marc Slemko , Assar Westerlund Subject: Re: bin/1805: Bug in ftpd Cc: Guido van Rooij , freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 14, 6:37pm, Marc Slemko wrote: } Subject: Re: bin/1805: Bug in ftpd } } Note that getpwent calls a bunch of NIS routines; they have to } be checked to see if they leave anything messy around. The probably do, but is it anything that isn't visible to an unprivileged ypcat? --- Truck From owner-freebsd-security Mon Oct 14 19:49:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA18518 for security-outgoing; Mon, 14 Oct 1996 19:49:00 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA18500 for ; Mon, 14 Oct 1996 19:48:54 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id UAA09350; Mon, 14 Oct 1996 20:48:12 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id UAA07301; Mon, 14 Oct 1996 20:46:15 -0600 (MDT) Date: Mon, 14 Oct 1996 20:46:14 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Jason Downs cc: freebsd-bugs@freefall.freebsd.org, freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <199610150130.SAA09758@threadway.teeny.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Jason's message was only sent to -bugs; I'm ccing it to -security too because there was discussion there] Jason's fix from the OpenBSD source tree follows. Since ftpd uses getpwnam which calls endpwent when it is done, the only other programs that we would need to worry about are those that call getpwent(3), and there shouldn't be many (if any) programs that do that and are exploitable. Index: src/lib/libc/db/hash/hash_buf.c =================================================================== RCS file: /cvs/src/lib/libc/db/hash/hash_buf.c,v retrieving revision 1.3 retrieving revision 1.4 diff -c -r1.3 -r1.4 *** hash_buf.c 1996/08/19 08:20:35 1.3 --- hash_buf.c 1996/10/14 22:17:27 1.4 *************** *** 35,41 **** */ #if defined(LIBC_SCCS) && !defined(lint) ! static char rcsid[] = "$OpenBSD: hash_buf.c,v 1.3 1996/08/19 08:20:35 tholo Exp $"; #endif /* LIBC_SCCS and not lint */ /* --- 35,41 ---- */ #if defined(LIBC_SCCS) && !defined(lint) ! static char rcsid[] = "$OpenBSD: hash_buf.c,v 1.4 1996/10/14 22:17:27 downsj Exp $"; #endif /* LIBC_SCCS and not lint */ /* *************** *** 331,338 **** } /* Check if we are freeing stuff */ if (do_free) { ! if (bp->page) free(bp->page); BUF_REMOVE(bp); free(bp); bp = LRU; --- 331,340 ---- } /* Check if we are freeing stuff */ if (do_free) { ! if (bp->page) { ! (void)memset(bp->page, 0, hashp->BSIZE); free(bp->page); + } BUF_REMOVE(bp); free(bp); bp = LRU; On Mon, 14 Oct 1996, Jason Downs wrote: > In message <199610141820.LAA14810@freefall.freebsd.org>, > Marc Slemko writes: > >The following reply was made to PR bin/1805; it has been noted by GNATS. > > > >From: Marc Slemko > >To: rkozak@bdk.lublin.pl > >Cc: freebsd-gnats-submit@freebsd.org > >Subject: Re: bin/1805: Bug in ftpd > >Date: Mon, 14 Oct 1996 12:11:11 -0600 (MDT) > > > > On Mon, 14 Oct 1996 rkozak@bdk.lublin..pl wrote: > > > > > While user is connected to server via ftp, the process ftpd is owned > > > by this user. When ftpd is abnormally termineted (e.g. kill -11 ) > > > the memory image of this process is writed to file ftpd.core in home dir. > > > This file contain encrypted passwords all users on this machine. > > > > That isn't nice. I don't think it will contain the passwords of all the > > users, just a certain subset of them. This also a problem with older > > versions of wuftpd, but the latest beta seems to be fine, although I'm not > > sure if that is just a fluke or by design. There are several possible > > fixes, but for those that need a temporary fix ASAP, a workaround follows. > > There should be no security problems with this, but there could be > > something I'm missing. > > I don't think disabling core dumps is a very clean or effective fix for this > problem. a.) the problem is potentially wide spread, and b.) is caused by > the design (limitations) of the DB library. > > The problem was killed by making essentially a one line change in the OpenBSD > source tree. A slight performance hit is exchanged for greater overall > security. > > > -- > Jason Downs (503) 256-8535 -/- (503) 952-3749 > downsj@teeny.org --> teeny.org: Free Software for a Free Internet <-- > http://www.teeny.org/ > OpenBSD: The BSD with a soul. http://www.openbsd.org/ > > From owner-freebsd-security Mon Oct 14 22:07:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA28080 for security-outgoing; Mon, 14 Oct 1996 22:07:30 -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 ESMTP id WAA28071 for ; Mon, 14 Oct 1996 22:07:26 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id PAA27672; Tue, 15 Oct 1996 15:03:04 +1000 Date: Tue, 15 Oct 1996 15:03:04 +1000 From: Bruce Evans Message-Id: <199610150503.PAA27672@godzilla.zeta.org.au> To: evans@fubar.cl.msu.edu, freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > At least on a FreeBSD 2.1.0-RELEASE #0 running wu-ftp version wu-2.4(3), >an ftpd core file shows about 33 encrypted entries in a password file of 667. This was probably fixed in March in -current but not in -stable. Setuid processes cannot dump core in -current. This makes them harder to debug of course. Bruce From owner-freebsd-security Tue Oct 15 08:53:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA15646 for security-outgoing; Tue, 15 Oct 1996 08:53:48 -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 IAA15634 for ; Tue, 15 Oct 1996 08:53:39 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id IAA28499; Tue, 15 Oct 1996 08:53:39 -0700 From: Nathan Lawson Message-Id: <199610151553.IAA28499@kdat.calpoly.edu> Subject: Re: bin/1805: Bug in ftpd To: marcs@znep.com (Marc Slemko) Date: Tue, 15 Oct 1996 08:53:38 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Marc Slemko" at Oct 14, 96 12:14:55 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 > > >Description: > > While user is connected to server via ftp, the process ftpd is owned > > by this user. When ftpd is abnormally termineted (e.g. kill -11 ) > > the memory image of this process is writed to file ftpd.core in home dir. > > This file contain encrypted passwords all users on this machine. > > > > > > >How-To-Repeat: > > 1. ftp localhost > > name: username > > password: **** > > 2. On second terminal: > > a) ps -ax | grep localhost > > b) kill -11 > > c) strings ~/ftpd.core | less (you will see all encrypted passwords). > > + > + /* > + * prevent ftpd from dumping core; necessary to prevent a user > + * from getting a core file with privileged information in > + */ > + rlim.rlim_cur = rlim.rlim_max = 0; > + if (setrlimit(RLIMIT_CORE, &rlim) != 0) { > + syslog(LOG_ERR, "setrlimit(RLIMIT_CORE, &rlim) failed"); > + exit(1); > + } > + This isn't a fix. Remember the principle of least privilege: if something doesn't need certain privileges, revoke them. In this case, the ftpd is running as the user. This means that all resources of ftpd are also owned by the user, including any inherited fds and memory. Your patch only fixes one instance of this attack, preventing core dumps. It is trivial to get around it by using ptrace to attach to the process and read the memory containing the encrypted passwords. The real fix is to close the password file and zero any associated memory immediately before the ftpd enters the user domain via setuid(). A user-level program does not need any authentication data (like passwords) and thus should not have any access to them. It's impossible to steal data that just isn't there. -- 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 Oct 15 09:11:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA16438 for security-outgoing; Tue, 15 Oct 1996 09:11:50 -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 JAA16391 for ; Tue, 15 Oct 1996 09:11:39 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id SAA04691; Tue, 15 Oct 1996 18:09:59 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199610151609.SAA04691@gvr.win.tue.nl> Subject: Re: bin/1805: Bug in ftpd To: assar@sics.se (Assar Westerlund) Date: Tue, 15 Oct 1996 18:09:59 +0200 (MET DST) Cc: marcs@znep.com, freebsd-security@FreeBSD.org In-Reply-To: <5lvicd6ufk.fsf@assaris.sics.se> from Assar Westerlund at "Oct 15, 96 00:40:46 am" 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 > > After the setuid, I will be able to make it dump core, or even better > use `ptrace' and then login will still have the file descriptor > pointing to /etc/spwd.db open and I can make it read the complete > shadow file. endpwent closes the spwd.db if I'm right so that would be impossible. -Guido From owner-freebsd-security Tue Oct 15 09:37:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA18129 for security-outgoing; Tue, 15 Oct 1996 09:37:30 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA18120 for ; Tue, 15 Oct 1996 09:37:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id JAA02562; Tue, 15 Oct 1996 09:38:44 -0700 (PDT) Message-Id: <199610151638.JAA02562@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Nathan Lawson cc: marcs@znep.com (Marc Slemko), freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-reply-to: Your message of "Tue, 15 Oct 1996 08:53:38 PDT." <199610151553.IAA28499@kdat.calpoly.edu> From: David Greenman Reply-To: dg@root.com Date: Tue, 15 Oct 1996 09:38:44 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >one instance of this attack, preventing core dumps. It is trivial to get >around it by using ptrace to attach to the process and read the memory >containing the encrypted passwords. At least in FreeBSD, you can't use ptrace-attach on a process that has changed its uid. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Oct 15 09:44:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA18580 for security-outgoing; Tue, 15 Oct 1996 09:44:10 -0700 (PDT) Received: from panacea.insight.co.za (panacea.insight.co.za [196.27.7.71]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA18571 for ; Tue, 15 Oct 1996 09:44:05 -0700 (PDT) Received: (from tony@localhost) by panacea.insight.co.za (8.8.0/8.7.3) id SAA07907 for freebsd-security@freebsd.org; Tue, 15 Oct 1996 18:41:12 GMT From: Tony Harverson Message-Id: <199610151841.SAA07907@panacea.insight.co.za> Subject: Realaudio & fwtk.. To: freebsd-security@freebsd.org Date: Tue, 15 Oct 1996 18:41:11 +0000 () X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Afternoon all, I just ran across this and thought those of you who were running fwtk sites might find it useful.... Realaudio have released a Real-audio Gateway which is intended as a plug-in to an fwtk firewall, and reference implementation for other firewall coders. It compiles clean as a whistle under 2.1.0... http://www.realaudio.com/help/firewall/proxyform.html T -- <+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+> || Tony Harverson | Network Admin || || Unix Admin | Trog@irc.insight || <+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+> Unix Rules all - Freebsd Forever :) From owner-freebsd-security Tue Oct 15 11:07:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25013 for security-outgoing; Tue, 15 Oct 1996 11:07:51 -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 LAA25006 for ; Tue, 15 Oct 1996 11:07:47 -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 TAA21583 for ; Tue, 15 Oct 1996 19:07:38 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA32013 for freebsd-security@freebsd.org; Tue, 15 Oct 1996 20:06:56 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.0/keltia-uucp-2.9) id TAA27258; Tue, 15 Oct 1996 19:37:11 +0200 (MET DST) Message-Id: <199610151737.TAA27258@keltia.freenix.fr> Date: Tue, 15 Oct 1996 19:37:11 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-security@FreeBSD.ORG Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <199610150503.PAA27672@godzilla.zeta.org.au>; from Bruce Evans on Oct 15, 1996 15:03:04 +1000 References: <199610150503.PAA27672@godzilla.zeta.org.au> X-Mailer: Mutt 0.47.13 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2564 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > This was probably fixed in March in -current but not in -stable. > Setuid processes cannot dump core in -current. This makes them harder > to debug of course. What did I miss ? wu-ftpd is not setuid... It is launched as root by inetd so the setuid-program-don't-core is not applicable. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #24: Thu Oct 10 19:35:39 MET DST 1996 From owner-freebsd-security Tue Oct 15 11:38:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27948 for security-outgoing; Tue, 15 Oct 1996 11:38:43 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA27925 for ; Tue, 15 Oct 1996 11:38:36 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id NAA01940; Tue, 15 Oct 1996 13:37:44 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Tue, 15 Oct 96 13:37 CDT Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.Beta.6/8.8.Beta.3) id NAA16749; Tue, 15 Oct 1996 13:37:36 -0500 (CDT) From: Karl Denninger Message-Id: <199610151837.NAA16749@Jupiter.Mcs.Net> Subject: Re: bin/1805: Bug in ftpd To: nlawson@kdat.csc.calpoly.edu (Nathan Lawson) Date: Tue, 15 Oct 1996 13:37:36 -0500 (CDT) Cc: marcs@znep.com, freebsd-security@freebsd.org In-Reply-To: <199610151553.IAA28499@kdat.calpoly.edu> from "Nathan Lawson" at Oct 15, 96 08:53:38 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > >Description: > > > While user is connected to server via ftp, the process ftpd is owned > > > by this user. When ftpd is abnormally termineted (e.g. kill -11 ) > > > the memory image of this process is writed to file ftpd.core in home dir. > > > This file contain encrypted passwords all users on this machine. > > > > > > > > > >How-To-Repeat: > > > 1. ftp localhost > > > name: username > > > password: **** > > > 2. On second terminal: > > > a) ps -ax | grep localhost > > > b) kill -11 > > > c) strings ~/ftpd.core | less (you will see all encrypted passwords). > > > > + > > + /* > > + * prevent ftpd from dumping core; necessary to prevent a user > > + * from getting a core file with privileged information in > > + */ > > + rlim.rlim_cur = rlim.rlim_max = 0; > > + if (setrlimit(RLIMIT_CORE, &rlim) != 0) { > > + syslog(LOG_ERR, "setrlimit(RLIMIT_CORE, &rlim) failed"); > > + exit(1); > > + } > > + > > This isn't a fix. Remember the principle of least privilege: if something > doesn't need certain privileges, revoke them. In this case, the ftpd is > running as the user. This means that all resources of ftpd are also owned > by the user, including any inherited fds and memory. Your patch only fixes > one instance of this attack, preventing core dumps. It is trivial to get > around it by using ptrace to attach to the process and read the memory > containing the encrypted passwords. > > The real fix is to close the password file and zero any associated memory > immediately before the ftpd enters the user domain via setuid(). A user-level > program does not need any authentication data (like passwords) and thus should > not have any access to them. > > It's impossible to steal data that just isn't there. > > -- > 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 Fundamentally, "endpwent()" should do this. But it does not. I suggest that the problem be patched there. That fixes *all* instances of this attack, provided that the code writers take a modicum of interest in the issue (ie: closing out open resources). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-security Tue Oct 15 12:10:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01016 for security-outgoing; Tue, 15 Oct 1996 12:10:23 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA01010 for ; Tue, 15 Oct 1996 12:10:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id MAA02970; Tue, 15 Oct 1996 12:11:24 -0700 (PDT) Message-Id: <199610151911.MAA02970@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: roberto@keltia.freenix.fr (Ollivier Robert) cc: freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd In-reply-to: Your message of "Tue, 15 Oct 1996 19:37:11 +0200." <199610151737.TAA27258@keltia.freenix.fr> From: David Greenman Reply-To: dg@root.com Date: Tue, 15 Oct 1996 12:11:24 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >According to Bruce Evans: >> This was probably fixed in March in -current but not in -stable. >> Setuid processes cannot dump core in -current. This makes them harder >> to debug of course. > >What did I miss ? wu-ftpd is not setuid... It is launched as root by inetd >so the setuid-program-don't-core is not applicable. Coredumps aren't created when the real uid != current uid, so no coredumps will be created for normal users. Unfortunately, this isn't true for anonymous ftp which runs as root. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Oct 15 12:54:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04000 for security-outgoing; Tue, 15 Oct 1996 12:54:34 -0700 (PDT) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA03995 for ; Tue, 15 Oct 1996 12:54:32 -0700 (PDT) Received: (from softweyr@localhost) by xmission.xmission.com (8.7.6/8.7.5) id NAA22380; Tue, 15 Oct 1996 13:54:29 -0600 (MDT) From: Softweyr LLC Message-Id: <199610151954.NAA22380@xmission.xmission.com> Subject: Re: bin/1805: Bug in ftpd To: karl@Mcs.Net (Karl Denninger) Date: Tue, 15 Oct 1996 13:54:28 -0600 (MDT) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199610151837.NAA16749@Jupiter.Mcs.Net> from "Karl Denninger" at Oct 15, 96 01:37:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Nate Lawson stated: % The real fix is to close the password file and zero any associated memory % immediately before the ftpd enters the user domain via setuid(). A user-level % program does not need any authentication data (like passwords) and thus should % not have any access to them. % % It's impossible to steal data that just isn't there. Karl Denninger replied: > Fundamentally, "endpwent()" should do this. > > But it does not. > > I suggest that the problem be patched there. That fixes *all* instances of > this attack, provided that the code writers take a modicum of interest in > the issue (ie: closing out open resources). Right. It should also overwrite and then free any allocated buffers that may contain secure information, such as encrypted passwords. This would assure us that a program whose euid has changed won't "inherit" any memory with critical information in it. Overwriting guarantees the critical data won't be left somewhere in the heap, even in free'd blocks. (BTW, is anal retentive supposed to be hyphenated? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Tue Oct 15 13:36:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06724 for security-outgoing; Tue, 15 Oct 1996 13:36:19 -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 ESMTP id NAA06716 for ; Tue, 15 Oct 1996 13:36:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id GAA21721; Wed, 16 Oct 1996 06:35:12 +1000 Date: Wed, 16 Oct 1996 06:35:12 +1000 From: Bruce Evans Message-Id: <199610152035.GAA21721@godzilla.zeta.org.au> To: freebsd-security@freebsd.org, roberto@keltia.freenix.fr Subject: Re: bin/1805: Bug in ftpd Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> This was probably fixed in March in -current but not in -stable. >> Setuid processes cannot dump core in -current. This makes them harder >> to debug of course. > >What did I miss ? wu-ftpd is not setuid... It is launched as root by inetd >so the setuid-program-don't-core is not applicable. It must have done a setuid(user) to become the user. This sets the P_SUGID flag, which is what prevents dumping core and ptrace/procfs attach . It doesn't matter whether the P_SUGID flag was set at exec time or later. Bruce From owner-freebsd-security Tue Oct 15 17:33:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA21259 for security-outgoing; Tue, 15 Oct 1996 17:33:42 -0700 (PDT) Received: from assaris.sics.se ([130.237.225.157]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA21253 for ; Tue, 15 Oct 1996 17:33:36 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.7.5/8.7.3) id CAA01593; Wed, 16 Oct 1996 02:15:29 +0200 (MET DST) To: guido@gvr.win.tue.nl (Guido van Rooij) Cc: marcs@znep.com, freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd References: <199610151609.SAA04691@gvr.win.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 16 Oct 1996 02:15:23 +0200 In-Reply-To: guido@gvr.win.tue.nl's message of Tue, 15 Oct 1996 18:09:59 +0200 (MET DST) Message-ID: <5l7mor7ois.fsf@assaris.sics.se> Lines: 12 X-Mailer: Gnus v5.2.40/Emacs 19.34 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk guido@gvr.win.tue.nl (Guido van Rooij) writes: > > After the setuid, I will be able to make it dump core, or even better > > use `ptrace' and then login will still have the file descriptor > > pointing to /etc/spwd.db open and I can make it read the complete > > shadow file. > > endpwent closes the spwd.db if I'm right so that would be impossible. Of course, it should call endpwent and endpwent should zero any incriminating memory, but it doesn't do that now. /assar From owner-freebsd-security Wed Oct 16 00:00:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA15064 for security-outgoing; Wed, 16 Oct 1996 00:00:15 -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 AAA15055 for ; Wed, 16 Oct 1996 00:00:05 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id IAA06582; Wed, 16 Oct 1996 08:59:41 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199610160659.IAA06582@gvr.win.tue.nl> Subject: Re: bin/1805: Bug in ftpd To: assar@sics.se (Assar Westerlund) Date: Wed, 16 Oct 1996 08:59:41 +0200 (MET DST) Cc: marcs@znep.com, freebsd-security@FreeBSD.org In-Reply-To: <5l7mor7ois.fsf@assaris.sics.se> from Assar Westerlund at "Oct 16, 96 02:15:23 am" 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 Assar Westerlund wrote: > guido@gvr.win.tue.nl (Guido van Rooij) writes: > > > After the setuid, I will be able to make it dump core, or even better > > > use `ptrace' and then login will still have the file descriptor > > > pointing to /etc/spwd.db open and I can make it read the complete > > > shadow file. > > > > endpwent closes the spwd.db if I'm right so that would be impossible. > > Of course, it should call endpwent and endpwent should zero any > incriminating memory, but it doesn't do that now. > No. He was talking about a filesdescriptor still pointing to the shadow password databse. That is not the case as endpwent closes it. -Guido From owner-freebsd-security Wed Oct 16 09:09:37 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11544 for security-outgoing; Wed, 16 Oct 1996 09:09:37 -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 JAA11535 for ; Wed, 16 Oct 1996 09:09:31 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id SAA07582; Wed, 16 Oct 1996 18:08:59 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199610161608.SAA07582@gvr.win.tue.nl> Subject: Re: bin/1805: Bug in ftpd To: assar@sics.se (Assar Westerlund) Date: Wed, 16 Oct 1996 18:08:59 +0200 (MET DST) Cc: marcs@znep.com, freebsd-security@FreeBSD.org In-Reply-To: <5l7mor7ois.fsf@assaris.sics.se> from Assar Westerlund at "Oct 16, 96 02:15:23 am" 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 Assar Westerlund wrote: > guido@gvr.win.tue.nl (Guido van Rooij) writes: > > > After the setuid, I will be able to make it dump core, or even better > > > use `ptrace' and then login will still have the file descriptor > > > pointing to /etc/spwd.db open and I can make it read the complete > > > shadow file. > > > > endpwent closes the spwd.db if I'm right so that would be impossible. > > Of course, it should call endpwent and endpwent should zero any > incriminating memory, but it doesn't do that now. Yes it does. Check the code. -Guido From owner-freebsd-security Wed Oct 16 10:08:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16521 for security-outgoing; Wed, 16 Oct 1996 10:08:42 -0700 (PDT) Received: from lucy.az.com (lucy.az.com [204.57.139.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA16509 for ; Wed, 16 Oct 1996 10:08:39 -0700 (PDT) Received: (from yankee@localhost) by lucy.az.com (8.6.12/8.6.12) id KAA05007; Wed, 16 Oct 1996 10:07:56 -0700 Date: Wed, 16 Oct 1996 10:07:56 -0700 (PDT) From: "az.com" To: freebsd-security@FreeBSD.org Subject: BUG IN FTPD In-Reply-To: <199610161608.SAA07582@gvr.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk would limit coredumpsize 0 in /etc/csh.cshrc also offer any relief? Dan From owner-freebsd-security Wed Oct 16 11:15:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22591 for security-outgoing; Wed, 16 Oct 1996 11:15:56 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA22584 for ; Wed, 16 Oct 1996 11:15:54 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.7.5/8.7.3) id UAA02696; Wed, 16 Oct 1996 20:15:16 +0200 (MET DST) To: guido@gvr.win.tue.nl (Guido van Rooij) Cc: marcs@znep.com, freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd References: <199610161608.SAA07582@gvr.win.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 16 Oct 1996 20:15:14 +0200 In-Reply-To: guido@gvr.win.tue.nl's message of Wed, 16 Oct 1996 18:08:59 +0200 (MET DST) Message-ID: <5laftm6aj1.fsf@assaris.sics.se> Lines: 20 X-Mailer: Gnus v5.2.40/Emacs 19.34 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk guido@gvr.win.tue.nl (Guido van Rooij) writes: > > guido@gvr.win.tue.nl (Guido van Rooij) writes: > > > > After the setuid, I will be able to make it dump core, or even better > > > > use `ptrace' and then login will still have the file descriptor > > > > pointing to /etc/spwd.db open and I can make it read the complete > > > > shadow file. > > > > > > endpwent closes the spwd.db if I'm right so that would be impossible. > > > > Of course, it should call endpwent and endpwent should zero any > > incriminating memory, but it doesn't do that now. > > Yes it does. Check the code. You're right. Some what other programs should we check to see that they really call endpwent? /assar From owner-freebsd-security Wed Oct 16 11:33:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA24079 for security-outgoing; Wed, 16 Oct 1996 11:33:47 -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 LAA24058 for ; Wed, 16 Oct 1996 11:33:39 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id UAA07947; Wed, 16 Oct 1996 20:33:13 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199610161833.UAA07947@gvr.win.tue.nl> Subject: Re: bin/1805: Bug in ftpd To: assar@sics.se (Assar Westerlund) Date: Wed, 16 Oct 1996 20:33:13 +0200 (MET DST) Cc: marcs@znep.com, freebsd-security@FreeBSD.org In-Reply-To: <5laftm6aj1.fsf@assaris.sics.se> from Assar Westerlund at "Oct 16, 96 08:15:14 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 Assar Westerlund wrote: > > Some what other programs should we check to see that they really call > endpwent? The ones that call getpw*. -Guido From owner-freebsd-security Wed Oct 16 14:33:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07900 for security-outgoing; Wed, 16 Oct 1996 14:33:51 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA07887 for ; Wed, 16 Oct 1996 14:33:38 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA14994; Wed, 16 Oct 1996 15:33:11 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA19407; Wed, 16 Oct 1996 15:15:22 -0600 (MDT) Date: Wed, 16 Oct 1996 15:15:22 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: "az.com" cc: freebsd-security@FreeBSD.org Subject: Re: BUG IN FTPD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk No. Things like login and ftpd are not started from a shell generally, so all thaat would do is stop coredumps for things started from csh, when csh read /etc/csh.cshrc, and if the user didn't override it. Stopping programs from core dumping (by something similar to the patch I suggested) does seem to fix the obvious ways of exploiting the problem, since you can't attach a debugger to a process that has changed UIDs, but a better solution is to have the appropriate buffers zeroed so the information just isn't there.... On Wed, 16 Oct 1996, az.com wrote: > > > would > > limit coredumpsize 0 > > in /etc/csh.cshrc > > also offer any relief? > > > Dan > From owner-freebsd-security Wed Oct 16 14:34:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07968 for security-outgoing; Wed, 16 Oct 1996 14:34:55 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA07960 for ; Wed, 16 Oct 1996 14:34:43 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA15020; Wed, 16 Oct 1996 15:34:17 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA19426; Wed, 16 Oct 1996 15:24:47 -0600 (MDT) Date: Wed, 16 Oct 1996 15:24:47 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Guido van Rooij , Assar Westerlund cc: freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd In-Reply-To: <5laftm6aj1.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 16 Oct 1996, Guido van Rooij wrote: > Assar Westerlund wrote: > > > > Some what other programs should we check to see that they really call > > endpwent? > > The ones that call getpw*. No, only the ones that call getpwent(3) _or_ call setpassent(3) or setpwent(3). Things like getpwnam call endpwent before they return. On 16 Oct 1996, Assar Westerlund wrote: > guido@gvr.win.tue.nl (Guido van Rooij) writes: > > > guido@gvr.win.tue.nl (Guido van Rooij) writes: > > > > > After the setuid, I will be able to make it dump core, or even better > > > > > use `ptrace' and then login will still have the file descriptor > > > > > pointing to /etc/spwd.db open and I can make it read the complete > > > > > shadow file. > > > > > > > > endpwent closes the spwd.db if I'm right so that would be impossible. > > > > > > Of course, it should call endpwent and endpwent should zero any > > > incriminating memory, but it doesn't do that now. > > > > Yes it does. Check the code. Is the "yes it does" referring to endpwent being called or to endpwent zeroing memory? endpwent is being called in ftpd (indirectly), but I don't see where endpwent is zeroing memory. Even if it was zeroing its memory, the DB routines are the ones that are leaving the junk behind. From owner-freebsd-security Thu Oct 17 15:59:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06806 for security-outgoing; Thu, 17 Oct 1996 15:59:46 -0700 (PDT) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA06800 for ; Thu, 17 Oct 1996 15:59:42 -0700 (PDT) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id QAA05452 for ; Thu, 17 Oct 1996 16:00:47 -0700 Date: Thu, 17 Oct 1996 16:00:45 -0700 (PDT) From: Veggy Vinny To: security@FreeBSD.ORG Subject: First security hole in sendmail 8.8.0 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Anyone know anything about this? Subject: First security hole in sendmail 8.8.0 Sent: 10/17 9:15 AM Received: 10/17 10:39 AM From: Tim Goodwin, tim@uunet.pipex.com To: djb-qmail@koobera.math.uic.edu Apparently there's a buffer overflow problem in sendmail 8.8.0's MIME handling code. Anyone who can send you mail can scribble on sendmail's stack, and have arbitrary code executed as root. http://web.eecs.nwu.edu/~jmyers/bugtraq/1497.html Tim. #include Rob Sansom Network Admin. Connectix Corp (415) 638-7398 sansom@connectix.com From owner-freebsd-security Thu Oct 17 23:00:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA28107 for security-outgoing; Thu, 17 Oct 1996 23:00:59 -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 XAA28102 for ; Thu, 17 Oct 1996 23:00:56 -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 HAA29654 for ; Fri, 18 Oct 1996 07:00:50 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id IAA14116 for security@FreeBSD.org; Fri, 18 Oct 1996 08:00:01 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.0/keltia-uucp-2.9) id HAA23697; Fri, 18 Oct 1996 07:59:07 +0200 (MET DST) Message-Id: <199610180559.HAA23697@keltia.freenix.fr> Date: Fri, 18 Oct 1996 07:59:07 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: security@FreeBSD.org Subject: Re: First security hole in sendmail 8.8.0 (fwd) In-Reply-To: ; from Veggy Vinny on Oct 17, 1996 16:00:45 -0700 References: X-Mailer: Mutt 0.47.13 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2584 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Veggy Vinny: > Anyone know anything about this? This is fixed in 8.8.1. It was the "= " handling at the end of the line that was a problem. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #25: Tue Oct 15 21:13:57 MET DST 1996 From owner-freebsd-security Fri Oct 18 16:15:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA00229 for security-outgoing; Fri, 18 Oct 1996 16:15:55 -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 QAA00179 for ; Fri, 18 Oct 1996 16:15:26 -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 BAA31795 for ; Sat, 19 Oct 1996 01:14:55 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id BAA25970 for security@FreeBSD.org; Sat, 19 Oct 1996 01:13:55 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.0/keltia-uucp-2.9) id AAA26441; Sat, 19 Oct 1996 00:23:30 +0200 (MET DST) Message-Id: <199610182223.AAA26441@keltia.freenix.fr> Date: Sat, 19 Oct 1996 00:23:30 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: security@FreeBSD.org Subject: Re: First security hole in sendmail 8.8.0 (fwd) In-Reply-To: <199610180559.HAA23697@keltia.freenix.fr>; from Ollivier Robert on Oct 18, 1996 07:59:07 +0200 References: <199610180559.HAA23697@keltia.freenix.fr> X-Mailer: Mutt 0.47.13 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2584 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Ollivier Robert: > This is fixed in 8.8.1. It was the "= " handling at the end of the line > that was a problem. Sigh. 8.8.2 is now out and this time is supposed to really fix the problem. The first patch was void. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #25: Tue Oct 15 21:13:57 MET DST 1996 From owner-freebsd-security Sat Oct 19 09:33:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21289 for security-outgoing; Sat, 19 Oct 1996 09:33:50 -0700 (PDT) Received: from iquest.net (iquest4.iquest.net [206.53.230.100]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA21284 for ; Sat, 19 Oct 1996 09:33:47 -0700 (PDT) Received: from jerryk.iquest.net by iquest.net with smtp (Smail3.1.29.1 #5) id m0vEeLH-00491SC; Sat, 19 Oct 96 11:33 EST Message-ID: <326902B1.F1A@iquest.net> Date: Sat, 19 Oct 1996 11:32:49 -0500 From: Jerry Kelley X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: FreeBSD Security List Subject: Any FreeBSD security topics of interest? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello all, I'm about to begin selection of my computer science MS thesis topic and was wondering if there are any security issues that would make for a reasonable thesis subject. I would really like something that could be implemented in FreeBSD and be made available to the world as my contribution to a great OS. If you have any issues or ideas that you'd like to see researched and explored, please let me know. Please feel free to send mail to the list or me personally if you prefer. Again, my goal is a new topic or improvement to security for UNIX that could be implemented (and added) to FreeBSD. I'd like to give something back to the FreeBSD community because I believe strongly in the principles of the a freely available OS. Thanks to all who reply. (You can be assured that if anyone provides an idea that I use I will make sure they receive credit.) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jerry Kelley jerryk@iquest.net "Expectations are life's greatest dangers." From owner-freebsd-security Sat Oct 19 15:21:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13541 for security-outgoing; Sat, 19 Oct 1996 15:21:59 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA13527 for ; Sat, 19 Oct 1996 15:21:51 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id PAA04600 for security@freebsd.org; Sat, 19 Oct 1996 15:21:45 -0700 Date: Sat, 19 Oct 1996 15:21:45 -0700 From: Sean Eric Fagan Message-Id: <199610192221.PAA04600@kithrup.com> To: security@freebsd.org Subject: Problems using kerberos 2.1.5<->1.1++ Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When I try kinit rlogin -L8x kithrup I get garbage instead of the plain text I expect to get; it is as if rlogin isn't handling the encryption properly. Anyone know what's going on? Thanks, Sean.