From owner-freebsd-security Sun Sep 14 23:06:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03150 for security-outgoing; Sun, 14 Sep 1997 23:06:55 -0700 (PDT) Received: from smtp.enteract.com (qmailr@rdist.org [207.229.129.22]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA03145 for ; Sun, 14 Sep 1997 23:06:52 -0700 (PDT) From: tqbf@rdist.org Received: (qmail 20016 invoked by uid 1001); 15 Sep 1997 06:06:44 -0000 Message-ID: <19970915060644.20015.qmail@smtp.enteract.com> Subject: OpenBSD Security Advisory: BSD I/O Signals To: freebsd-security@freebsd.org Date: Mon, 15 Sep 1997 01:06:44 -0500 (CDT) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------------------------------------------------------------------------- OpenBSD Security Advisory September 15, 1997 Vulnerability in I/O Signal Handling ---------------------------------------------------------------------------- SYNOPSIS A vulnerability discovered in the 4.4BSD kernel allows unprivileged users to send certain signals to arbitrary processes on the system. Depending on the operating system and targeted program, this may allow users to kill off processes or disrupt the operation of certain programs. ---------------------------------------------------------------------------- AFFECTED SYSTEMS This vulnerability has been tested on all available 4.4BSD-based operating systems, including BSDI, NetBSD, OpenBSD, and FreeBSD, in their most recent release revisions. Additionally, this problem is known to affect SGI IRIX, and may affect other operating systems as well. ---------------------------------------------------------------------------- DETAILS Certain programs implemented in Unix operating systems make use of a facility called "asynchronous I/O" to handle multiple tasks simultaneously. Asynchronous I/O allows a process to be notified whenever it has data that needs to be read from an input source; the kernel notifies the process using a signal. Asynchronous I/O is enabled on a descriptor using the fcntl() system call; a descriptor with the O_ASYNC flag set will cause a signal to be sent whenever there is data available to be read from it. Additionally, using the FIOASYNC ioctl(), asynchronous notification can be enabled on a descriptor. In cases where multiple processes are used in an application, it becomes useful to allow a descriptor to notify other processes as well. This is accomplished by use of another fcntl() operation, F_SETOWN, as well as an ioctl, FIOSETOWN (certain devices also provide an interface to this facility with the TIOCSPGRP ioctl). These operations allow a program to set the process or process group that will receive signal notification of pending I/O. A lack of checking in the code that handles these operations allows a program to specify an arbitrary process ID when using a socket or device file descriptor. By setting the recipient of signal notification to a process that is not owned by the program, the kernel can be tricked into signalling arbitrary programs. Additionally, vulnerable kernels do not keep track of the credentials associated with a process when determining whether to send I/O signals; because of this, it is possible to specify the PID of a process that is owned by an attacker, and then destroy that process and wait for it's PID to be re-used. The new process occupying that PID can then be signalled by the attacker, regardless of it's owner. It's important to note that operating systems that check credentials when a program attempts to set the PID for I/O notification (thus evading part of this vulnerability) may still be vulnerable to the latter problem (process ID re-use), if credentials aren't checked at signal delivery time. We recommend that concerned parties contact their operating system vendors or support channels to verify their vulnerability status. ---------------------------------------------------------------------------- TECHNICAL DETAILS This vulnerability exists due to a lack of credential checking in the kernel when setting the recipient of I/O notification. BSD-based kernels maintain this information in descriptor-specific data structures unrelated to the process table; the vulnerability discussed here involves sockets, which maintain the signal recipient in the per-descriptor "socket" structure, although certain devices provide similar facilities and vulnerabilities. On 4.4BSD systems, the signal normally sent to inform a process of pending I/O is SIGIO. The default disposition of the SIGIO signal is "ignore" - thus, most processes are unaffected by this vulnerability. However, certain programs explicitly catch SIGIO in order to use asynchronous I/O; these programs can be disrupted by sending stray SIGIO's. The process notification information is also used to determine the process that receives notification of out-of-band data on a socket. The same vulnerability applies, this time by setting the process to notify and then sending a message with the MSG_OOB flag set; the targetted process will receive a SIGURG signal. Certain network daemons (ftpd, for instance) can be disrupted by being sent a stray SIGURG signal when no data is available for reading. The problem is more serious on vulnerable System V operating systems; in many cases, SIGIO is the equivalent of SIGPOLL, and the default disposition of that signal is "terminate process". On SGI's IRIX operating system, exploitation of this vulnerability can kill any process on the system. In addition to being an extremely potent denial of service attack, surgical application of this vulnerability can be used to compromise the system - for example, a process holding a bound address (NFS port 2049, for instance) can be killed off and it's port stolen; this can be used to steal NFS file handles. In addition to sockets, some devices also provide facilities for notification of pending I/O; examples include the "log", "tun", and "bpf". The BPF and tunnel devices are of minimal concern, as they are not typically accessible by arbitrary users (although BPF is interesting in that it will allow the owner of a bpf-associated descriptor to choose an arbitrary signal to send, including SIGSTOP). Unfortunately, the log device is normally accessible by users, and can be used to perform the same attack as sockets allow. It's also worth noting that the interface that allows programs to set the process to receive notification of I/O on the log device renders the legitimate purpose of this facility totally unreliable; unrelated programs can seize control of the asynchronous I/O notification on the log device, causing programs that rely on it to fail. The provided patches do not attempt to resolve this problem. ---------------------------------------------------------------------------- RESOLUTION This is a kernel problem that can only be fixed by patching the problematic system code. Patches for the OpenBSD operating system are provided in this advisory; FreeBSD is known to be working on a similar resolution. The provided OpenBSD patch causes the kernel to keep track of the credentials of the process associated with an I/O object; the credentials are checked whenever I/O notification will occur, and therefore resolve both the F_SETOWN and PID-reuse problems. Device drivers that present an interface to I/O notification must be modified to check credentials when the TIOCSPGRP (or equivalent) ioctl() is used to set notificatio PID; the OpenBSD patch resolves all currently known occurances of this in that operating system. ---------------------------------------------------------------------------- CREDITS This vulnerability is believed to have been discovered originally by Alan Peakall. Documentation and testing of this problem was conducted by Theo de Raadt and the OpenBSD development team; SGI information was obtained from Timothy Newsham. The OpenBSD patch for this vulnerability was written in a caffeinated haze by Theo de Raadt of the OpenBSD project. The developers at OpenBSD would like to thank Perry Metzger for his continuous support of their work. ---------------------------------------------------------------------------- OPENBSD PATCH Index: sys/signalvar.h =================================================================== RCS file: /cvs/src/sys/sys/signalvar.h,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- signalvar.h 1997/02/01 21:49:36 1.6 +++ signalvar.h 1997/08/31 20:42:01 1.7 @@ -156,6 +156,7 @@ int coredump __P((struct proc *p)); void execsigs __P((struct proc *p)); void gsignal __P((int pgid, int sig)); +void csignal __P((pid_t pgid, int signum, uid_t uid, uid_t euid)); int issignal __P((struct proc *p)); void pgsignal __P((struct pgrp *pgrp, int sig, int checkctty)); void postsig __P((int sig)); Index: sys/socketvar.h =================================================================== RCS file: /cvs/src/sys/sys/socketvar.h,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- socketvar.h 1997/02/28 04:04:13 1.10 +++ socketvar.h 1997/08/31 20:42:02 1.11 @@ -71,6 +71,8 @@ short so_timeo; /* connection timeout */ u_short so_error; /* error affecting connection */ pid_t so_pgid; /* pgid for signals */ + uid_t so_siguid; /* uid of process who set so_pgid */ + uid_t so_sigeuid; /* euid of process who set so_pgid */ u_long so_oobmark; /* chars to oob mark */ /* * Variables for socket buffering. Index: kern/kern_descrip.c =================================================================== RCS file: /cvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- kern_descrip.c 1997/08/21 05:17:37 1.13 +++ kern_descrip.c 1997/08/31 20:42:15 1.14 @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -251,8 +252,11 @@ case F_SETOWN: if (fp->f_type == DTYPE_SOCKET) { - ((struct socket *)fp->f_data)->so_pgid = - (long)SCARG(uap, arg); + struct socket *so = (struct socket *)fp->f_data; + + so->so_pgid = (long)SCARG(uap, arg); + so->so_siguid = p->p_cred->p_ruid; + so->so_sigeuid = p->p_ucred->cr_uid; return (0); } if ((long)SCARG(uap, arg) <= 0) { Index: kern/kern_sig.c =================================================================== RCS file: /cvs/src/sys/kern/kern_sig.c,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- kern_sig.c 1997/02/01 21:49:41 1.16 +++ kern_sig.c 1997/08/31 20:42:18 1.17 @@ -481,6 +481,46 @@ } } return (nfound ? 0 : ESRCH); +} + +#define CANDELIVER(uid, euid, p) \ + (euid == 0 || \ + (uid) == (p)->p_cred->p_ruid || \ + (uid) == (p)->p_cred->p_svuid || \ + (uid) == (p)->p_ucred->cr_uid || \ + (euid) == (p)->p_cred->p_ruid || \ + (euid) == (p)->p_cred->p_svuid || \ + (euid) == (p)->p_ucred->cr_uid) + +/* + * Deliver signum to pgid, but first check uid/euid against each + * process and see if it is permitted. + */ +void +csignal(pgid, signum, uid, euid) + pid_t pgid; + int signum; + uid_t uid, euid; +{ + struct pgrp *pgrp; + struct proc *p; + + if (pgid == 0) + return; + if (pgid < 0) { + pgid = -pgid; + if ((pgrp = pgfind(pgid)) == NULL) + return; + for (p = pgrp->pg_members.lh_first; p; + p = p->p_pglist.le_next) + if (CANDELIVER(uid, euid, p)) + psignal(p, signum); + } else { + if ((p = pfind(pgid)) == NULL) + return; + if (CANDELIVER(uid, euid, p)) + psignal(p, signum); + } } /* Index: kern/subr_log.c =================================================================== RCS file: /cvs/src/sys/kern/subr_log.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- subr_log.c 1996/04/21 22:27:17 1.3 +++ subr_log.c 1997/08/31 20:42:20 1.4 @@ -60,6 +60,8 @@ int sc_state; /* see above for possibilities */ struct selinfo sc_selp; /* process waiting on select call */ int sc_pgid; /* process/group for async I/O */ + uid_t sc_siguid; /* uid for process that set sc_pgid */ + uid_t sc_sigeuid; /* euid for process that set sc_pgid */ } logsoftc; int log_open; /* also used in log() */ @@ -179,17 +181,12 @@ void logwakeup() { - struct proc *p; - if (!log_open) return; selwakeup(&logsoftc.sc_selp); - if (logsoftc.sc_state & LOG_ASYNC) { - if (logsoftc.sc_pgid < 0) - gsignal(-logsoftc.sc_pgid, SIGIO); - else if ((p = pfind(logsoftc.sc_pgid)) != NULL) - psignal(p, SIGIO); - } + if (logsoftc.sc_state & LOG_ASYNC) + csignal(logsoftc.sc_pgid, SIGIO, + logsoftc.sc_siguid, logsoftc.sc_sigeuid); if (logsoftc.sc_state & LOG_RDWAIT) { wakeup((caddr_t)msgbufp); logsoftc.sc_state &= ~LOG_RDWAIT; @@ -232,6 +229,8 @@ case TIOCSPGRP: logsoftc.sc_pgid = *(int *)data; + logsoftc.sc_siguid = p->p_cred->p_ruid; + logsoftc.sc_sigeuid = p->p_ucred->cr_uid; break; case TIOCGPGRP: Index: kern/sys_generic.c =================================================================== RCS file: /cvs/src/sys/kern/sys_generic.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- sys_generic.c 1997/01/27 23:21:13 1.7 +++ sys_generic.c 1997/08/31 20:42:21 1.8 @@ -480,7 +480,11 @@ case FIOSETOWN: tmp = *(int *)data; if (fp->f_type == DTYPE_SOCKET) { - ((struct socket *)fp->f_data)->so_pgid = tmp; + struct socket *so = (struct socket *)fp->f_data; + + so->so_pgid = tmp; + so->so_siguid = p->p_cred->p_ruid; + so->so_sigeuid = p->p_ucred->cr_uid; error = 0; break; } Index: kern/sys_socket.c =================================================================== RCS file: /cvs/src/sys/kern/sys_socket.c,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- sys_socket.c 1997/02/24 14:19:59 1.2 +++ sys_socket.c 1997/08/31 20:42:23 1.3 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -112,6 +113,8 @@ case SIOCSPGRP: so->so_pgid = *(int *)data; + so->so_siguid = p->p_cred->p_ruid; + so->so_sigeuid = p->p_ucred->cr_uid; return (0); case SIOCGPGRP: Index: kern/uipc_socket.c =================================================================== RCS file: /cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.15 retrieving revision 1.17 diff -u -r1.15 -r1.17 --- uipc_socket.c 1997/06/29 18:14:35 1.15 +++ uipc_socket.c 1997/08/31 20:42:24 1.17 @@ -1058,11 +1060,6 @@ sohasoutofband(so) register struct socket *so; { - struct proc *p; - - if (so->so_pgid < 0) - gsignal(-so->so_pgid, SIGURG); - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) - psignal(p, SIGURG); + csignal(so->so_pgid, SIGURG, so->so_siguid, so->so_sigeuid); selwakeup(&so->so_rcv.sb_sel); } Index: kern/uipc_socket2.c =================================================================== RCS file: /cvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- uipc_socket2.c 1997/02/21 08:45:00 1.5 +++ uipc_socket2.c 1997/08/31 20:42:26 1.6 @@ -315,20 +315,14 @@ register struct socket *so; register struct sockbuf *sb; { - struct proc *p; - selwakeup(&sb->sb_sel); sb->sb_flags &= ~SB_SEL; if (sb->sb_flags & SB_WAIT) { sb->sb_flags &= ~SB_WAIT; wakeup((caddr_t)&sb->sb_cc); } - if (so->so_state & SS_ASYNC) { - if (so->so_pgid < 0) - gsignal(-so->so_pgid, SIGIO); - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) - psignal(p, SIGIO); - } + if (so->so_state & SS_ASYNC) + csignal(so->so_pgid, SIGIO, so->so_siguid, so->so_sigeuid); } /* Index: net/bpf.c =================================================================== RCS file: /cvs/src/sys/net/bpf.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- bpf.c 1997/03/17 16:29:37 1.9 +++ bpf.c 1997/08/31 20:42:29 1.10 @@ -522,14 +522,10 @@ bpf_wakeup(d) register struct bpf_d *d; { - struct proc *p; - wakeup((caddr_t)d); if (d->bd_async && d->bd_sig) - if (d->bd_pgid > 0) - gsignal (d->bd_pgid, d->bd_sig); - else if ((p = pfind (-d->bd_pgid)) != NULL) - psignal (p, d->bd_sig); + csignal(d->bd_pgid, d->bd_sig, + d->bd_siguid, d->bd_sigeuid); #if BSD >= 199103 selwakeup(&d->bd_sel); @@ -822,6 +818,8 @@ */ case TIOCSPGRP: /* Process or group to send signals to */ d->bd_pgid = *(int *)addr; + d->bd_siguid = p->p_cred->p_ruid; + d->bd_sigeuid = p->p_ucred->cr_uid; break; case TIOCGPGRP: Index: net/bpfdesc.h =================================================================== RCS file: /cvs/src/sys/net/bpfdesc.h,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- bpfdesc.h 1997/02/24 13:33:56 1.2 +++ bpfdesc.h 1997/08/31 20:42:30 1.3 @@ -77,6 +77,8 @@ int bd_async; /* non-zero if packet reception should generate signal */ int bd_sig; /* signal to send upon packet reception */ pid_t bd_pgid; /* process or group id for signal */ + uid_t bd_siguid; /* uid for process that set pgid */ + uid_t bd_sigeuid; /* euid for process that set pgid */ #if BSD < 199103 u_char bd_selcoll; /* true if selects collide */ int bd_timedout; Index: net/if_tun.c =================================================================== RCS file: /cvs/src/sys/net/if_tun.c,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- if_tun.c 1997/07/29 07:18:20 1.19 +++ if_tun.c 1997/08/31 20:42:32 1.20 @@ -84,7 +84,9 @@ struct tun_softc { u_short tun_flags; /* misc flags */ struct ifnet tun_if; /* the interface */ - int tun_pgrp; /* the process group - if any */ + pid_t tun_pgid; /* the process group - if any */ + uid_t tun_siguid; /* uid for process that set tun_pgid */ + uid_t tun_sigeuid; /* euid for process that set tun_pgid */ struct selinfo tun_rsel; /* read select */ struct selinfo tun_wsel; /* write select (not used) */ }; @@ -228,7 +230,7 @@ } splx(s); } - tp->tun_pgrp = 0; + tp->tun_pgid = 0; selwakeup(&tp->tun_rsel); TUNDEBUG(("%s: closed\n", ifp->if_xname)); @@ -331,7 +333,6 @@ { struct tun_softc *tp = ifp->if_softc; struct tunnel_header *th; - struct proc *p; int s; TUNDEBUG(("%s: tun_output\n", ifp->if_xname)); @@ -371,12 +372,9 @@ tp->tun_flags &= ~TUN_RWAIT; wakeup((caddr_t)tp); } - if (tp->tun_flags & TUN_ASYNC && tp->tun_pgrp) { - if (tp->tun_pgrp > 0) - gsignal(tp->tun_pgrp, SIGIO); - else if ((p = pfind(-tp->tun_pgrp)) != NULL) - psignal(p, SIGIO); - } + if (tp->tun_flags & TUN_ASYNC && tp->tun_pgid) + csignal(tp->tun_pgid, SIGIO, + tp->tun_siguid, tp->tun_sigeuid); selwakeup(&tp->tun_rsel); return 0; } @@ -446,10 +444,12 @@ splx(s); break; case TIOCSPGRP: - tp->tun_pgrp = *(int *)data; + tp->tun_pgid = *(int *)data; + tp->tun_siguid = p->p_cred->p_ruid; + tp->tun_sigeuid = p->p_ucred->cr_uid; break; case TIOCGPGRP: - *(int *)data = tp->tun_pgrp; + *(int *)data = tp->tun_pgid; break; default: splx(s); From owner-freebsd-security Sun Sep 14 23:53:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA06070 for security-outgoing; Sun, 14 Sep 1997 23:53:42 -0700 (PDT) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA06059 for ; Sun, 14 Sep 1997 23:53:35 -0700 (PDT) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id QAA05056 for security@freebsd.org; Mon, 15 Sep 1997 16:53:31 +1000 From: Darren Reed Message-Id: <199709150653.QAA05056@plum.cyber.com.au> Subject: OpenBSD Security Advisory: BSD I/O Signals (fwd) To: security@freebsd.org Date: Mon, 15 Sep 1997 16:53:29 +1000 (EST) Priority: urgent X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from tqbf@rdist.org, sie wrote > From tech-security-owner-darrenr=cyber.com.au@NetBSD.ORG Mon Sep 15 16:10:11 1997 > Message-ID: <19970915060810.20028.qmail@smtp.enteract.com> > From: tqbf@rdist.org > Subject: OpenBSD Security Advisory: BSD I/O Signals > To: tech-security@NetBSD.ORG > Date: Mon, 15 Sep 1997 01:08:10 -0500 (CDT) > Reply-To: tqbf@enteract.com > X-Mailer: ELM [version 2.4ME+ PL31 (25)] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: tech-security-owner@NetBSD.ORG > Precedence: list > Delivered-To: tech-security@NetBSD.ORG > > ---------------------------------------------------------------------------- > > OpenBSD Security Advisory > > September 15, 1997 > > Vulnerability in I/O Signal Handling > > ---------------------------------------------------------------------------- > > SYNOPSIS > > A vulnerability discovered in the 4.4BSD kernel allows unprivileged users > to send certain signals to arbitrary processes on the system. Depending on > the operating system and targeted program, this may allow users to kill > off processes or disrupt the operation of certain programs. > > ---------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > This vulnerability has been tested on all available 4.4BSD-based operating > systems, including BSDI, NetBSD, OpenBSD, and FreeBSD, in their most > recent release revisions. Additionally, this problem is known to affect > SGI IRIX, and may affect other operating systems as well. > > ---------------------------------------------------------------------------- > > DETAILS > > Certain programs implemented in Unix operating systems make use of a > facility called "asynchronous I/O" to handle multiple tasks > simultaneously. Asynchronous I/O allows a process to be notified whenever > it has data that needs to be read from an input source; the kernel > notifies the process using a signal. > > Asynchronous I/O is enabled on a descriptor using the fcntl() system call; > a descriptor with the O_ASYNC flag set will cause a signal to be sent > whenever there is data available to be read from it. Additionally, using > the FIOASYNC ioctl(), asynchronous notification can be enabled on a > descriptor. > > In cases where multiple processes are used in an application, it becomes > useful to allow a descriptor to notify other processes as well. This is > accomplished by use of another fcntl() operation, F_SETOWN, as well as an > ioctl, FIOSETOWN (certain devices also provide an interface to this > facility with the TIOCSPGRP ioctl). These operations allow a program to > set the process or process group that will receive signal notification of > pending I/O. > > A lack of checking in the code that handles these operations allows a > program to specify an arbitrary process ID when using a socket or device > file descriptor. By setting the recipient of signal notification to a > process that is not owned by the program, the kernel can be tricked into > signalling arbitrary programs. > > Additionally, vulnerable kernels do not keep track of the credentials > associated with a process when determining whether to send I/O signals; > because of this, it is possible to specify the PID of a process that is > owned by an attacker, and then destroy that process and wait for it's PID > to be re-used. The new process occupying that PID can then be signalled by > the attacker, regardless of it's owner. > > It's important to note that operating systems that check credentials when > a program attempts to set the PID for I/O notification (thus evading part > of this vulnerability) may still be vulnerable to the latter problem > (process ID re-use), if credentials aren't checked at signal delivery > time. We recommend that concerned parties contact their operating system > vendors or support channels to verify their vulnerability status. > > ---------------------------------------------------------------------------- > > TECHNICAL DETAILS > > This vulnerability exists due to a lack of credential checking in the > kernel when setting the recipient of I/O notification. BSD-based > kernels maintain this information in descriptor-specific data structures > unrelated to the process table; the vulnerability discussed here involves > sockets, which maintain the signal recipient in the per-descriptor > "socket" structure, although certain devices provide similar facilities > and vulnerabilities. > > On 4.4BSD systems, the signal normally sent to inform a process of pending > I/O is SIGIO. The default disposition of the SIGIO signal is "ignore" - > thus, most processes are unaffected by this vulnerability. However, > certain programs explicitly catch SIGIO in order to use asynchronous I/O; > these programs can be disrupted by sending stray SIGIO's. > > The process notification information is also used to determine the process > that receives notification of out-of-band data on a socket. The same > vulnerability applies, this time by setting the process to notify and then > sending a message with the MSG_OOB flag set; the targetted process will > receive a SIGURG signal. Certain network daemons (ftpd, for instance) can > be disrupted by being sent a stray SIGURG signal when no data is available > for reading. > > The problem is more serious on vulnerable System V operating systems; in > many cases, SIGIO is the equivalent of SIGPOLL, and the default > disposition of that signal is "terminate process". On SGI's IRIX operating > system, exploitation of this vulnerability can kill any process on the > system. > > In addition to being an extremely potent denial of service attack, > surgical application of this vulnerability can be used to compromise the > system - for example, a process holding a bound address (NFS port 2049, > for instance) can be killed off and it's port stolen; this can be used to > steal NFS file handles. > > In addition to sockets, some devices also provide facilities for > notification of pending I/O; examples include the "log", "tun", and "bpf". > The BPF and tunnel devices are of minimal concern, as they are not > typically accessible by arbitrary users (although BPF is interesting in > that it will allow the owner of a bpf-associated descriptor to choose an > arbitrary signal to send, including SIGSTOP). > > Unfortunately, the log device is normally accessible by users, and can be > used to perform the same attack as sockets allow. It's also worth noting > that the interface that allows programs to set the process to receive > notification of I/O on the log device renders the legitimate purpose of > this facility totally unreliable; unrelated programs can seize control of > the asynchronous I/O notification on the log device, causing programs that > rely on it to fail. The provided patches do not attempt to resolve this > problem. > > ---------------------------------------------------------------------------- > > RESOLUTION > > This is a kernel problem that can only be fixed by patching the > problematic system code. Patches for the OpenBSD operating system are > provided in this advisory; FreeBSD is known to be working on a similar > resolution. > > The provided OpenBSD patch causes the kernel to keep track of the > credentials of the process associated with an I/O object; the credentials > are checked whenever I/O notification will occur, and therefore resolve > both the F_SETOWN and PID-reuse problems. Device drivers that present an > interface to I/O notification must be modified to check credentials when > the TIOCSPGRP (or equivalent) ioctl() is used to set notificatio PID; the > OpenBSD patch resolves all currently known occurances of this in that > operating system. > > ---------------------------------------------------------------------------- > > CREDITS > > This vulnerability is believed to have been discovered originally by Alan > Peakall. Documentation and testing of this problem was conducted by Theo > de Raadt and the OpenBSD development team; SGI information was obtained > from Timothy Newsham. > > The OpenBSD patch for this vulnerability was written in a caffeinated haze > by Theo de Raadt of the OpenBSD project. > > The developers at OpenBSD would like to thank Perry Metzger for his > continuous support of their work. > > ---------------------------------------------------------------------------- > > OPENBSD PATCH > > Index: sys/signalvar.h > =================================================================== > RCS file: /cvs/src/sys/sys/signalvar.h,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- signalvar.h 1997/02/01 21:49:36 1.6 > +++ signalvar.h 1997/08/31 20:42:01 1.7 > @@ -156,6 +156,7 @@ > int coredump __P((struct proc *p)); > void execsigs __P((struct proc *p)); > void gsignal __P((int pgid, int sig)); > +void csignal __P((pid_t pgid, int signum, uid_t uid, uid_t euid)); > int issignal __P((struct proc *p)); > void pgsignal __P((struct pgrp *pgrp, int sig, int checkctty)); > void postsig __P((int sig)); > Index: sys/socketvar.h > =================================================================== > RCS file: /cvs/src/sys/sys/socketvar.h,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- socketvar.h 1997/02/28 04:04:13 1.10 > +++ socketvar.h 1997/08/31 20:42:02 1.11 > @@ -71,6 +71,8 @@ > short so_timeo; /* connection timeout */ > u_short so_error; /* error affecting connection */ > pid_t so_pgid; /* pgid for signals */ > + uid_t so_siguid; /* uid of process who set so_pgid */ > + uid_t so_sigeuid; /* euid of process who set so_pgid */ > u_long so_oobmark; /* chars to oob mark */ > /* > * Variables for socket buffering. > Index: kern/kern_descrip.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_descrip.c,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -r1.13 -r1.14 > --- kern_descrip.c 1997/08/21 05:17:37 1.13 > +++ kern_descrip.c 1997/08/31 20:42:15 1.14 > @@ -55,6 +55,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -251,8 +252,11 @@ > > case F_SETOWN: > if (fp->f_type == DTYPE_SOCKET) { > - ((struct socket *)fp->f_data)->so_pgid = > - (long)SCARG(uap, arg); > + struct socket *so = (struct socket *)fp->f_data; > + > + so->so_pgid = (long)SCARG(uap, arg); > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > return (0); > } > if ((long)SCARG(uap, arg) <= 0) { > Index: kern/kern_sig.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_sig.c,v > retrieving revision 1.16 > retrieving revision 1.17 > diff -u -r1.16 -r1.17 > --- kern_sig.c 1997/02/01 21:49:41 1.16 > +++ kern_sig.c 1997/08/31 20:42:18 1.17 > @@ -481,6 +481,46 @@ > } > } > return (nfound ? 0 : ESRCH); > +} > + > +#define CANDELIVER(uid, euid, p) \ > + (euid == 0 || \ > + (uid) == (p)->p_cred->p_ruid || \ > + (uid) == (p)->p_cred->p_svuid || \ > + (uid) == (p)->p_ucred->cr_uid || \ > + (euid) == (p)->p_cred->p_ruid || \ > + (euid) == (p)->p_cred->p_svuid || \ > + (euid) == (p)->p_ucred->cr_uid) > + > +/* > + * Deliver signum to pgid, but first check uid/euid against each > + * process and see if it is permitted. > + */ > +void > +csignal(pgid, signum, uid, euid) > + pid_t pgid; > + int signum; > + uid_t uid, euid; > +{ > + struct pgrp *pgrp; > + struct proc *p; > + > + if (pgid == 0) > + return; > + if (pgid < 0) { > + pgid = -pgid; > + if ((pgrp = pgfind(pgid)) == NULL) > + return; > + for (p = pgrp->pg_members.lh_first; p; > + p = p->p_pglist.le_next) > + if (CANDELIVER(uid, euid, p)) > + psignal(p, signum); > + } else { > + if ((p = pfind(pgid)) == NULL) > + return; > + if (CANDELIVER(uid, euid, p)) > + psignal(p, signum); > + } > } > > /* > Index: kern/subr_log.c > =================================================================== > RCS file: /cvs/src/sys/kern/subr_log.c,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- subr_log.c 1996/04/21 22:27:17 1.3 > +++ subr_log.c 1997/08/31 20:42:20 1.4 > @@ -60,6 +60,8 @@ > int sc_state; /* see above for possibilities */ > struct selinfo sc_selp; /* process waiting on select call */ > int sc_pgid; /* process/group for async I/O */ > + uid_t sc_siguid; /* uid for process that set sc_pgid */ > + uid_t sc_sigeuid; /* euid for process that set sc_pgid */ > } logsoftc; > > int log_open; /* also used in log() */ > @@ -179,17 +181,12 @@ > void > logwakeup() > { > - struct proc *p; > - > if (!log_open) > return; > selwakeup(&logsoftc.sc_selp); > - if (logsoftc.sc_state & LOG_ASYNC) { > - if (logsoftc.sc_pgid < 0) > - gsignal(-logsoftc.sc_pgid, SIGIO); > - else if ((p = pfind(logsoftc.sc_pgid)) != NULL) > - psignal(p, SIGIO); > - } > + if (logsoftc.sc_state & LOG_ASYNC) > + csignal(logsoftc.sc_pgid, SIGIO, > + logsoftc.sc_siguid, logsoftc.sc_sigeuid); > if (logsoftc.sc_state & LOG_RDWAIT) { > wakeup((caddr_t)msgbufp); > logsoftc.sc_state &= ~LOG_RDWAIT; > @@ -232,6 +229,8 @@ > > case TIOCSPGRP: > logsoftc.sc_pgid = *(int *)data; > + logsoftc.sc_siguid = p->p_cred->p_ruid; > + logsoftc.sc_sigeuid = p->p_ucred->cr_uid; > break; > > case TIOCGPGRP: > Index: kern/sys_generic.c > =================================================================== > RCS file: /cvs/src/sys/kern/sys_generic.c,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- sys_generic.c 1997/01/27 23:21:13 1.7 > +++ sys_generic.c 1997/08/31 20:42:21 1.8 > @@ -480,7 +480,11 @@ > case FIOSETOWN: > tmp = *(int *)data; > if (fp->f_type == DTYPE_SOCKET) { > - ((struct socket *)fp->f_data)->so_pgid = tmp; > + struct socket *so = (struct socket *)fp->f_data; > + > + so->so_pgid = tmp; > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > error = 0; > break; > } > Index: kern/sys_socket.c > =================================================================== > RCS file: /cvs/src/sys/kern/sys_socket.c,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- sys_socket.c 1997/02/24 14:19:59 1.2 > +++ sys_socket.c 1997/08/31 20:42:23 1.3 > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -112,6 +113,8 @@ > > case SIOCSPGRP: > so->so_pgid = *(int *)data; > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > return (0); > > case SIOCGPGRP: > Index: kern/uipc_socket.c > =================================================================== > RCS file: /cvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.15 > retrieving revision 1.17 > diff -u -r1.15 -r1.17 > --- uipc_socket.c 1997/06/29 18:14:35 1.15 > +++ uipc_socket.c 1997/08/31 20:42:24 1.17 > @@ -1058,11 +1060,6 @@ > sohasoutofband(so) > register struct socket *so; > { > - struct proc *p; > - > - if (so->so_pgid < 0) > - gsignal(-so->so_pgid, SIGURG); > - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) > - psignal(p, SIGURG); > + csignal(so->so_pgid, SIGURG, so->so_siguid, so->so_sigeuid); > selwakeup(&so->so_rcv.sb_sel); > } > Index: kern/uipc_socket2.c > =================================================================== > RCS file: /cvs/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -r1.5 -r1.6 > --- uipc_socket2.c 1997/02/21 08:45:00 1.5 > +++ uipc_socket2.c 1997/08/31 20:42:26 1.6 > @@ -315,20 +315,14 @@ > register struct socket *so; > register struct sockbuf *sb; > { > - struct proc *p; > - > selwakeup(&sb->sb_sel); > sb->sb_flags &= ~SB_SEL; > if (sb->sb_flags & SB_WAIT) { > sb->sb_flags &= ~SB_WAIT; > wakeup((caddr_t)&sb->sb_cc); > } > - if (so->so_state & SS_ASYNC) { > - if (so->so_pgid < 0) > - gsignal(-so->so_pgid, SIGIO); > - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) > - psignal(p, SIGIO); > - } > + if (so->so_state & SS_ASYNC) > + csignal(so->so_pgid, SIGIO, so->so_siguid, so->so_sigeuid); > } > > /* > Index: net/bpf.c > =================================================================== > RCS file: /cvs/src/sys/net/bpf.c,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -u -r1.9 -r1.10 > --- bpf.c 1997/03/17 16:29:37 1.9 > +++ bpf.c 1997/08/31 20:42:29 1.10 > @@ -522,14 +522,10 @@ > bpf_wakeup(d) > register struct bpf_d *d; > { > - struct proc *p; > - > wakeup((caddr_t)d); > if (d->bd_async && d->bd_sig) > - if (d->bd_pgid > 0) > - gsignal (d->bd_pgid, d->bd_sig); > - else if ((p = pfind (-d->bd_pgid)) != NULL) > - psignal (p, d->bd_sig); > + csignal(d->bd_pgid, d->bd_sig, > + d->bd_siguid, d->bd_sigeuid); > > #if BSD >= 199103 > selwakeup(&d->bd_sel); > @@ -822,6 +818,8 @@ > */ > case TIOCSPGRP: /* Process or group to send signals to */ > d->bd_pgid = *(int *)addr; > + d->bd_siguid = p->p_cred->p_ruid; > + d->bd_sigeuid = p->p_ucred->cr_uid; > break; > > case TIOCGPGRP: > Index: net/bpfdesc.h > =================================================================== > RCS file: /cvs/src/sys/net/bpfdesc.h,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- bpfdesc.h 1997/02/24 13:33:56 1.2 > +++ bpfdesc.h 1997/08/31 20:42:30 1.3 > @@ -77,6 +77,8 @@ > int bd_async; /* non-zero if packet reception should generate signal */ > int bd_sig; /* signal to send upon packet reception */ > pid_t bd_pgid; /* process or group id for signal */ > + uid_t bd_siguid; /* uid for process that set pgid */ > + uid_t bd_sigeuid; /* euid for process that set pgid */ > #if BSD < 199103 > u_char bd_selcoll; /* true if selects collide */ > int bd_timedout; > Index: net/if_tun.c > =================================================================== > RCS file: /cvs/src/sys/net/if_tun.c,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -u -r1.19 -r1.20 > --- if_tun.c 1997/07/29 07:18:20 1.19 > +++ if_tun.c 1997/08/31 20:42:32 1.20 > @@ -84,7 +84,9 @@ > struct tun_softc { > u_short tun_flags; /* misc flags */ > struct ifnet tun_if; /* the interface */ > - int tun_pgrp; /* the process group - if any */ > + pid_t tun_pgid; /* the process group - if any */ > + uid_t tun_siguid; /* uid for process that set tun_pgid */ > + uid_t tun_sigeuid; /* euid for process that set tun_pgid */ > struct selinfo tun_rsel; /* read select */ > struct selinfo tun_wsel; /* write select (not used) */ > }; > @@ -228,7 +230,7 @@ > } > splx(s); > } > - tp->tun_pgrp = 0; > + tp->tun_pgid = 0; > selwakeup(&tp->tun_rsel); > > TUNDEBUG(("%s: closed\n", ifp->if_xname)); > @@ -331,7 +333,6 @@ > { > struct tun_softc *tp = ifp->if_softc; > struct tunnel_header *th; > - struct proc *p; > int s; > > TUNDEBUG(("%s: tun_output\n", ifp->if_xname)); > @@ -371,12 +372,9 @@ > tp->tun_flags &= ~TUN_RWAIT; > wakeup((caddr_t)tp); > } > - if (tp->tun_flags & TUN_ASYNC && tp->tun_pgrp) { > - if (tp->tun_pgrp > 0) > - gsignal(tp->tun_pgrp, SIGIO); > - else if ((p = pfind(-tp->tun_pgrp)) != NULL) > - psignal(p, SIGIO); > - } > + if (tp->tun_flags & TUN_ASYNC && tp->tun_pgid) > + csignal(tp->tun_pgid, SIGIO, > + tp->tun_siguid, tp->tun_sigeuid); > selwakeup(&tp->tun_rsel); > return 0; > } > @@ -446,10 +444,12 @@ > splx(s); > break; > case TIOCSPGRP: > - tp->tun_pgrp = *(int *)data; > + tp->tun_pgid = *(int *)data; > + tp->tun_siguid = p->p_cred->p_ruid; > + tp->tun_sigeuid = p->p_ucred->cr_uid; > break; > case TIOCGPGRP: > - *(int *)data = tp->tun_pgrp; > + *(int *)data = tp->tun_pgid; > break; > default: > splx(s); > > > From owner-freebsd-security Mon Sep 15 06:05:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27647 for security-outgoing; Mon, 15 Sep 1997 06:05:02 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27628 for ; Mon, 15 Sep 1997 06:04:50 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id JAA01383; Mon, 15 Sep 1997 09:04:36 -0400 (EDT) Date: Mon, 15 Sep 1997 09:04:33 -0400 (EDT) From: Brian Mitchell To: tqbf@enteract.com cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-Reply-To: <19970915060644.20015.qmail@smtp.enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997 tqbf@rdist.org wrote: Didnt linux have almost this exact same problem like 2 years ago? > ---------------------------------------------------------------------------- > > OpenBSD Security Advisory > > September 15, 1997 > > Vulnerability in I/O Signal Handling > > ---------------------------------------------------------------------------- > > SYNOPSIS > > A vulnerability discovered in the 4.4BSD kernel allows unprivileged users > to send certain signals to arbitrary processes on the system. Depending on > the operating system and targeted program, this may allow users to kill > off processes or disrupt the operation of certain programs. > > ---------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > This vulnerability has been tested on all available 4.4BSD-based operating > systems, including BSDI, NetBSD, OpenBSD, and FreeBSD, in their most > recent release revisions. Additionally, this problem is known to affect > SGI IRIX, and may affect other operating systems as well. > > ---------------------------------------------------------------------------- > > DETAILS > > Certain programs implemented in Unix operating systems make use of a > facility called "asynchronous I/O" to handle multiple tasks > simultaneously. Asynchronous I/O allows a process to be notified whenever > it has data that needs to be read from an input source; the kernel > notifies the process using a signal. > > Asynchronous I/O is enabled on a descriptor using the fcntl() system call; > a descriptor with the O_ASYNC flag set will cause a signal to be sent > whenever there is data available to be read from it. Additionally, using > the FIOASYNC ioctl(), asynchronous notification can be enabled on a > descriptor. > > In cases where multiple processes are used in an application, it becomes > useful to allow a descriptor to notify other processes as well. This is > accomplished by use of another fcntl() operation, F_SETOWN, as well as an > ioctl, FIOSETOWN (certain devices also provide an interface to this > facility with the TIOCSPGRP ioctl). These operations allow a program to > set the process or process group that will receive signal notification of > pending I/O. > > A lack of checking in the code that handles these operations allows a > program to specify an arbitrary process ID when using a socket or device > file descriptor. By setting the recipient of signal notification to a > process that is not owned by the program, the kernel can be tricked into > signalling arbitrary programs. > > Additionally, vulnerable kernels do not keep track of the credentials > associated with a process when determining whether to send I/O signals; > because of this, it is possible to specify the PID of a process that is > owned by an attacker, and then destroy that process and wait for it's PID > to be re-used. The new process occupying that PID can then be signalled by > the attacker, regardless of it's owner. > > It's important to note that operating systems that check credentials when > a program attempts to set the PID for I/O notification (thus evading part > of this vulnerability) may still be vulnerable to the latter problem > (process ID re-use), if credentials aren't checked at signal delivery > time. We recommend that concerned parties contact their operating system > vendors or support channels to verify their vulnerability status. > > ---------------------------------------------------------------------------- > > TECHNICAL DETAILS > > This vulnerability exists due to a lack of credential checking in the > kernel when setting the recipient of I/O notification. BSD-based > kernels maintain this information in descriptor-specific data structures > unrelated to the process table; the vulnerability discussed here involves > sockets, which maintain the signal recipient in the per-descriptor > "socket" structure, although certain devices provide similar facilities > and vulnerabilities. > > On 4.4BSD systems, the signal normally sent to inform a process of pending > I/O is SIGIO. The default disposition of the SIGIO signal is "ignore" - > thus, most processes are unaffected by this vulnerability. However, > certain programs explicitly catch SIGIO in order to use asynchronous I/O; > these programs can be disrupted by sending stray SIGIO's. > > The process notification information is also used to determine the process > that receives notification of out-of-band data on a socket. The same > vulnerability applies, this time by setting the process to notify and then > sending a message with the MSG_OOB flag set; the targetted process will > receive a SIGURG signal. Certain network daemons (ftpd, for instance) can > be disrupted by being sent a stray SIGURG signal when no data is available > for reading. > > The problem is more serious on vulnerable System V operating systems; in > many cases, SIGIO is the equivalent of SIGPOLL, and the default > disposition of that signal is "terminate process". On SGI's IRIX operating > system, exploitation of this vulnerability can kill any process on the > system. > > In addition to being an extremely potent denial of service attack, > surgical application of this vulnerability can be used to compromise the > system - for example, a process holding a bound address (NFS port 2049, > for instance) can be killed off and it's port stolen; this can be used to > steal NFS file handles. > > In addition to sockets, some devices also provide facilities for > notification of pending I/O; examples include the "log", "tun", and "bpf". > The BPF and tunnel devices are of minimal concern, as they are not > typically accessible by arbitrary users (although BPF is interesting in > that it will allow the owner of a bpf-associated descriptor to choose an > arbitrary signal to send, including SIGSTOP). > > Unfortunately, the log device is normally accessible by users, and can be > used to perform the same attack as sockets allow. It's also worth noting > that the interface that allows programs to set the process to receive > notification of I/O on the log device renders the legitimate purpose of > this facility totally unreliable; unrelated programs can seize control of > the asynchronous I/O notification on the log device, causing programs that > rely on it to fail. The provided patches do not attempt to resolve this > problem. > > ---------------------------------------------------------------------------- > > RESOLUTION > > This is a kernel problem that can only be fixed by patching the > problematic system code. Patches for the OpenBSD operating system are > provided in this advisory; FreeBSD is known to be working on a similar > resolution. > > The provided OpenBSD patch causes the kernel to keep track of the > credentials of the process associated with an I/O object; the credentials > are checked whenever I/O notification will occur, and therefore resolve > both the F_SETOWN and PID-reuse problems. Device drivers that present an > interface to I/O notification must be modified to check credentials when > the TIOCSPGRP (or equivalent) ioctl() is used to set notificatio PID; the > OpenBSD patch resolves all currently known occurances of this in that > operating system. > > ---------------------------------------------------------------------------- > > CREDITS > > This vulnerability is believed to have been discovered originally by Alan > Peakall. Documentation and testing of this problem was conducted by Theo > de Raadt and the OpenBSD development team; SGI information was obtained > from Timothy Newsham. > > The OpenBSD patch for this vulnerability was written in a caffeinated haze > by Theo de Raadt of the OpenBSD project. > > The developers at OpenBSD would like to thank Perry Metzger for his > continuous support of their work. > > ---------------------------------------------------------------------------- > > OPENBSD PATCH > > Index: sys/signalvar.h > =================================================================== > RCS file: /cvs/src/sys/sys/signalvar.h,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- signalvar.h 1997/02/01 21:49:36 1.6 > +++ signalvar.h 1997/08/31 20:42:01 1.7 > @@ -156,6 +156,7 @@ > int coredump __P((struct proc *p)); > void execsigs __P((struct proc *p)); > void gsignal __P((int pgid, int sig)); > +void csignal __P((pid_t pgid, int signum, uid_t uid, uid_t euid)); > int issignal __P((struct proc *p)); > void pgsignal __P((struct pgrp *pgrp, int sig, int checkctty)); > void postsig __P((int sig)); > Index: sys/socketvar.h > =================================================================== > RCS file: /cvs/src/sys/sys/socketvar.h,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- socketvar.h 1997/02/28 04:04:13 1.10 > +++ socketvar.h 1997/08/31 20:42:02 1.11 > @@ -71,6 +71,8 @@ > short so_timeo; /* connection timeout */ > u_short so_error; /* error affecting connection */ > pid_t so_pgid; /* pgid for signals */ > + uid_t so_siguid; /* uid of process who set so_pgid */ > + uid_t so_sigeuid; /* euid of process who set so_pgid */ > u_long so_oobmark; /* chars to oob mark */ > /* > * Variables for socket buffering. > Index: kern/kern_descrip.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_descrip.c,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -r1.13 -r1.14 > --- kern_descrip.c 1997/08/21 05:17:37 1.13 > +++ kern_descrip.c 1997/08/31 20:42:15 1.14 > @@ -55,6 +55,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -251,8 +252,11 @@ > > case F_SETOWN: > if (fp->f_type == DTYPE_SOCKET) { > - ((struct socket *)fp->f_data)->so_pgid = > - (long)SCARG(uap, arg); > + struct socket *so = (struct socket *)fp->f_data; > + > + so->so_pgid = (long)SCARG(uap, arg); > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > return (0); > } > if ((long)SCARG(uap, arg) <= 0) { > Index: kern/kern_sig.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_sig.c,v > retrieving revision 1.16 > retrieving revision 1.17 > diff -u -r1.16 -r1.17 > --- kern_sig.c 1997/02/01 21:49:41 1.16 > +++ kern_sig.c 1997/08/31 20:42:18 1.17 > @@ -481,6 +481,46 @@ > } > } > return (nfound ? 0 : ESRCH); > +} > + > +#define CANDELIVER(uid, euid, p) \ > + (euid == 0 || \ > + (uid) == (p)->p_cred->p_ruid || \ > + (uid) == (p)->p_cred->p_svuid || \ > + (uid) == (p)->p_ucred->cr_uid || \ > + (euid) == (p)->p_cred->p_ruid || \ > + (euid) == (p)->p_cred->p_svuid || \ > + (euid) == (p)->p_ucred->cr_uid) > + > +/* > + * Deliver signum to pgid, but first check uid/euid against each > + * process and see if it is permitted. > + */ > +void > +csignal(pgid, signum, uid, euid) > + pid_t pgid; > + int signum; > + uid_t uid, euid; > +{ > + struct pgrp *pgrp; > + struct proc *p; > + > + if (pgid == 0) > + return; > + if (pgid < 0) { > + pgid = -pgid; > + if ((pgrp = pgfind(pgid)) == NULL) > + return; > + for (p = pgrp->pg_members.lh_first; p; > + p = p->p_pglist.le_next) > + if (CANDELIVER(uid, euid, p)) > + psignal(p, signum); > + } else { > + if ((p = pfind(pgid)) == NULL) > + return; > + if (CANDELIVER(uid, euid, p)) > + psignal(p, signum); > + } > } > > /* > Index: kern/subr_log.c > =================================================================== > RCS file: /cvs/src/sys/kern/subr_log.c,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- subr_log.c 1996/04/21 22:27:17 1.3 > +++ subr_log.c 1997/08/31 20:42:20 1.4 > @@ -60,6 +60,8 @@ > int sc_state; /* see above for possibilities */ > struct selinfo sc_selp; /* process waiting on select call */ > int sc_pgid; /* process/group for async I/O */ > + uid_t sc_siguid; /* uid for process that set sc_pgid */ > + uid_t sc_sigeuid; /* euid for process that set sc_pgid */ > } logsoftc; > > int log_open; /* also used in log() */ > @@ -179,17 +181,12 @@ > void > logwakeup() > { > - struct proc *p; > - > if (!log_open) > return; > selwakeup(&logsoftc.sc_selp); > - if (logsoftc.sc_state & LOG_ASYNC) { > - if (logsoftc.sc_pgid < 0) > - gsignal(-logsoftc.sc_pgid, SIGIO); > - else if ((p = pfind(logsoftc.sc_pgid)) != NULL) > - psignal(p, SIGIO); > - } > + if (logsoftc.sc_state & LOG_ASYNC) > + csignal(logsoftc.sc_pgid, SIGIO, > + logsoftc.sc_siguid, logsoftc.sc_sigeuid); > if (logsoftc.sc_state & LOG_RDWAIT) { > wakeup((caddr_t)msgbufp); > logsoftc.sc_state &= ~LOG_RDWAIT; > @@ -232,6 +229,8 @@ > > case TIOCSPGRP: > logsoftc.sc_pgid = *(int *)data; > + logsoftc.sc_siguid = p->p_cred->p_ruid; > + logsoftc.sc_sigeuid = p->p_ucred->cr_uid; > break; > > case TIOCGPGRP: > Index: kern/sys_generic.c > =================================================================== > RCS file: /cvs/src/sys/kern/sys_generic.c,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- sys_generic.c 1997/01/27 23:21:13 1.7 > +++ sys_generic.c 1997/08/31 20:42:21 1.8 > @@ -480,7 +480,11 @@ > case FIOSETOWN: > tmp = *(int *)data; > if (fp->f_type == DTYPE_SOCKET) { > - ((struct socket *)fp->f_data)->so_pgid = tmp; > + struct socket *so = (struct socket *)fp->f_data; > + > + so->so_pgid = tmp; > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > error = 0; > break; > } > Index: kern/sys_socket.c > =================================================================== > RCS file: /cvs/src/sys/kern/sys_socket.c,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- sys_socket.c 1997/02/24 14:19:59 1.2 > +++ sys_socket.c 1997/08/31 20:42:23 1.3 > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -112,6 +113,8 @@ > > case SIOCSPGRP: > so->so_pgid = *(int *)data; > + so->so_siguid = p->p_cred->p_ruid; > + so->so_sigeuid = p->p_ucred->cr_uid; > return (0); > > case SIOCGPGRP: > Index: kern/uipc_socket.c > =================================================================== > RCS file: /cvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.15 > retrieving revision 1.17 > diff -u -r1.15 -r1.17 > --- uipc_socket.c 1997/06/29 18:14:35 1.15 > +++ uipc_socket.c 1997/08/31 20:42:24 1.17 > @@ -1058,11 +1060,6 @@ > sohasoutofband(so) > register struct socket *so; > { > - struct proc *p; > - > - if (so->so_pgid < 0) > - gsignal(-so->so_pgid, SIGURG); > - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) > - psignal(p, SIGURG); > + csignal(so->so_pgid, SIGURG, so->so_siguid, so->so_sigeuid); > selwakeup(&so->so_rcv.sb_sel); > } > Index: kern/uipc_socket2.c > =================================================================== > RCS file: /cvs/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -r1.5 -r1.6 > --- uipc_socket2.c 1997/02/21 08:45:00 1.5 > +++ uipc_socket2.c 1997/08/31 20:42:26 1.6 > @@ -315,20 +315,14 @@ > register struct socket *so; > register struct sockbuf *sb; > { > - struct proc *p; > - > selwakeup(&sb->sb_sel); > sb->sb_flags &= ~SB_SEL; > if (sb->sb_flags & SB_WAIT) { > sb->sb_flags &= ~SB_WAIT; > wakeup((caddr_t)&sb->sb_cc); > } > - if (so->so_state & SS_ASYNC) { > - if (so->so_pgid < 0) > - gsignal(-so->so_pgid, SIGIO); > - else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) > - psignal(p, SIGIO); > - } > + if (so->so_state & SS_ASYNC) > + csignal(so->so_pgid, SIGIO, so->so_siguid, so->so_sigeuid); > } > > /* > Index: net/bpf.c > =================================================================== > RCS file: /cvs/src/sys/net/bpf.c,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -u -r1.9 -r1.10 > --- bpf.c 1997/03/17 16:29:37 1.9 > +++ bpf.c 1997/08/31 20:42:29 1.10 > @@ -522,14 +522,10 @@ > bpf_wakeup(d) > register struct bpf_d *d; > { > - struct proc *p; > - > wakeup((caddr_t)d); > if (d->bd_async && d->bd_sig) > - if (d->bd_pgid > 0) > - gsignal (d->bd_pgid, d->bd_sig); > - else if ((p = pfind (-d->bd_pgid)) != NULL) > - psignal (p, d->bd_sig); > + csignal(d->bd_pgid, d->bd_sig, > + d->bd_siguid, d->bd_sigeuid); > > #if BSD >= 199103 > selwakeup(&d->bd_sel); > @@ -822,6 +818,8 @@ > */ > case TIOCSPGRP: /* Process or group to send signals to */ > d->bd_pgid = *(int *)addr; > + d->bd_siguid = p->p_cred->p_ruid; > + d->bd_sigeuid = p->p_ucred->cr_uid; > break; > > case TIOCGPGRP: > Index: net/bpfdesc.h > =================================================================== > RCS file: /cvs/src/sys/net/bpfdesc.h,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- bpfdesc.h 1997/02/24 13:33:56 1.2 > +++ bpfdesc.h 1997/08/31 20:42:30 1.3 > @@ -77,6 +77,8 @@ > int bd_async; /* non-zero if packet reception should generate signal */ > int bd_sig; /* signal to send upon packet reception */ > pid_t bd_pgid; /* process or group id for signal */ > + uid_t bd_siguid; /* uid for process that set pgid */ > + uid_t bd_sigeuid; /* euid for process that set pgid */ > #if BSD < 199103 > u_char bd_selcoll; /* true if selects collide */ > int bd_timedout; > Index: net/if_tun.c > =================================================================== > RCS file: /cvs/src/sys/net/if_tun.c,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -u -r1.19 -r1.20 > --- if_tun.c 1997/07/29 07:18:20 1.19 > +++ if_tun.c 1997/08/31 20:42:32 1.20 > @@ -84,7 +84,9 @@ > struct tun_softc { > u_short tun_flags; /* misc flags */ > struct ifnet tun_if; /* the interface */ > - int tun_pgrp; /* the process group - if any */ > + pid_t tun_pgid; /* the process group - if any */ > + uid_t tun_siguid; /* uid for process that set tun_pgid */ > + uid_t tun_sigeuid; /* euid for process that set tun_pgid */ > struct selinfo tun_rsel; /* read select */ > struct selinfo tun_wsel; /* write select (not used) */ > }; > @@ -228,7 +230,7 @@ > } > splx(s); > } > - tp->tun_pgrp = 0; > + tp->tun_pgid = 0; > selwakeup(&tp->tun_rsel); > > TUNDEBUG(("%s: closed\n", ifp->if_xname)); > @@ -331,7 +333,6 @@ > { > struct tun_softc *tp = ifp->if_softc; > struct tunnel_header *th; > - struct proc *p; > int s; > > TUNDEBUG(("%s: tun_output\n", ifp->if_xname)); > @@ -371,12 +372,9 @@ > tp->tun_flags &= ~TUN_RWAIT; > wakeup((caddr_t)tp); > } > - if (tp->tun_flags & TUN_ASYNC && tp->tun_pgrp) { > - if (tp->tun_pgrp > 0) > - gsignal(tp->tun_pgrp, SIGIO); > - else if ((p = pfind(-tp->tun_pgrp)) != NULL) > - psignal(p, SIGIO); > - } > + if (tp->tun_flags & TUN_ASYNC && tp->tun_pgid) > + csignal(tp->tun_pgid, SIGIO, > + tp->tun_siguid, tp->tun_sigeuid); > selwakeup(&tp->tun_rsel); > return 0; > } > @@ -446,10 +444,12 @@ > splx(s); > break; > case TIOCSPGRP: > - tp->tun_pgrp = *(int *)data; > + tp->tun_pgid = *(int *)data; > + tp->tun_siguid = p->p_cred->p_ruid; > + tp->tun_sigeuid = p->p_ucred->cr_uid; > break; > case TIOCGPGRP: > - *(int *)data = tp->tun_pgrp; > + *(int *)data = tp->tun_pgid; > break; > default: > splx(s); > > > From owner-freebsd-security Mon Sep 15 19:06:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA12896 for security-outgoing; Mon, 15 Sep 1997 19:06:25 -0700 (PDT) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA12885 for ; Mon, 15 Sep 1997 19:06:20 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id HAA17279; Mon, 15 Sep 1997 07:45:40 -0700 (PDT) Message-Id: <199709151445.HAA17279@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd017275; Mon Sep 15 14:45:10 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: Brian Mitchell cc: tqbf@enteract.com, freebsd-security@freebsd.org Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-reply-to: Your message of "Mon, 15 Sep 1997 09:04:33 EDT." Date: Mon, 15 Sep 1997 07:45:09 -0700 From: Cy Schubert Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 15 Sep 1997 tqbf@rdist.org wrote: > > Didnt linux have almost this exact same problem like 2 years ago? It did, it may have even been about three years ago (about the same time of the syslog() bug). At that time the Linux networking code took a lot of code from Net/2. > > > > --------------------------------------------------------------------------- - > > > > OpenBSD Security Advisory > > > > September 15, 1997 > > > > Vulnerability in I/O Signal Handling Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Sep 16 09:16:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03044 for security-outgoing; Tue, 16 Sep 1997 09:16:36 -0700 (PDT) Received: from methan.chemie.fu-berlin.de (methan.chemie.fu-berlin.de [160.45.22.81]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA03038 for ; Tue, 16 Sep 1997 09:16:30 -0700 (PDT) Received: by methan.chemie.fu-berlin.de (Smail3.1.29.1) from uriela.in-berlin.de (192.109.42.147) with smtp id ; Tue, 16 Sep 97 18:16 MET DST Received: by uriela.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.8) from never.never.mind.de (193.101.72.4) with smtp id m0xB0Gr-000LsvC; Tue, 16 Sep 97 18:14 MET DST Received: by never.never.mind.de (linux Smail3.1.28.1 #1) id m0xB0Hw-000EdyC; Tue, 16 Sep 97 18:15 MET DST Received: (from ripley@localhost) by nortobor.nostromo.in-berlin.de (8.8.5/8.8.5) id TAA17801; Mon, 15 Sep 1997 19:19:43 +0200 (CEST) From: "H. Eckert" Message-Id: <199709151719.TAA17801@nortobor.nostromo.in-berlin.de> Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-Reply-To: from Brian Mitchell at "Sep 15, 97 09:04:33 am" To: brian@firehouse.net (Brian Mitchell) Date: Mon, 15 Sep 1997 19:19:42 +0200 (CEST) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Mitchell wrote: > On Mon, 15 Sep 1997 tqbf@rdist.org wrote: > > Didnt linux have almost this exact same problem like 2 years ago? > [ *550* lines of quotation deleted ] Oh boy, what happend to everybodys' editors DELETE-LINE key ? -- H. Eckert, 10777 Berlin, Germany ISO 8859-1: Ä=Ae, Ö=Oe, Ü=Ue, ä=ae, ö=oe, ü=ue, ß=sz. "(Technobabbel)" (Jetrel) - "Müssen wir uns diesen Schwachsinn wirklich anhören?" (Neelix) From owner-freebsd-security Tue Sep 16 09:52:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05169 for security-outgoing; Tue, 16 Sep 1997 09:52:34 -0700 (PDT) Received: from silence.secnet.com (silence.secnet.com [199.185.231.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05164 for ; Tue, 16 Sep 1997 09:52:29 -0700 (PDT) From: tqbf@silence.secnet.com Received: from localhost (tqbf@localhost) by silence.secnet.com (8.8.5/secnet) with SMTP id LAA25058; Tue, 16 Sep 1997 11:01:51 -0600 (MDT) Date: Tue, 16 Sep 1997 11:01:51 -0600 (MDT) To: Brian Mitchell cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Brian Mitchell wrote: > On Mon, 15 Sep 1997 tqbf@rdist.org wrote: > > Didnt linux have almost this exact same problem like 2 years ago? I am happy not to know anything about Linux problems. =) ---------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ---------------------------------------------------------------------- "mmm... sacrilicious..." From owner-freebsd-security Tue Sep 16 20:35:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA10120 for security-outgoing; Tue, 16 Sep 1997 20:35:26 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA10115 for ; Tue, 16 Sep 1997 20:35:24 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id UAA29763; Tue, 16 Sep 1997 20:35:15 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id UAA29545; Tue, 16 Sep 1997 20:35:14 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id UAA26150; Tue, 16 Sep 1997 20:35:13 -0700 (PDT) From: Don Lewis Message-Id: <199709170335.UAA26150@salsa.gv.tsc.tdk.com> Date: Tue, 16 Sep 1997 20:35:13 -0700 In-Reply-To: tqbf@rdist.org "OpenBSD Security Advisory: BSD I/O Signals" (Sep 15, 1:06am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 15, 1:06am, tqbf@rdist.org wrote: } Subject: OpenBSD Security Advisory: BSD I/O Signals } In cases where multiple processes are used in an application, it becomes } useful to allow a descriptor to notify other processes as well. This is } accomplished by use of another fcntl() operation, F_SETOWN, as well as an } ioctl, FIOSETOWN (certain devices also provide an interface to this } facility with the TIOCSPGRP ioctl). These operations allow a program to } set the process or process group that will receive signal notification of } pending I/O. Should the argument to F_SETOWN undergo similar checks as the argument to tcsetpgrp()? I don't think it makes sense to allow F_SETOWN to enable signals to be sent to processes in a different session. There probably need to be more calls to setsid() sprinkled around as well, for instance in inetd. } A lack of checking in the code that handles these operations allows a } program to specify an arbitrary process ID when using a socket or device } file descriptor. By setting the recipient of signal notification to a } process that is not owned by the program, the kernel can be tricked into } signalling arbitrary programs. } } Additionally, vulnerable kernels do not keep track of the credentials } associated with a process when determining whether to send I/O signals; } because of this, it is possible to specify the PID of a process that is } owned by an attacker, and then destroy that process and wait for it's PID } to be re-used. The new process occupying that PID can then be signalled by } the attacker, regardless of it's owner. I think a better cure for the wraparound problem is to solve it the same was as it is handled for controlling terminals. When the process group associated with a controlling terminal disappears, the terminal loses it's process group and it no longer can send signals. This would have to be extended to handle either processes or process groups for F_SETOWN. This also has some positive performance implications, since it potentially bypasses a lot calls to pfind() and pgfind(). } It's important to note that operating systems that check credentials when } a program attempts to set the PID for I/O notification (thus evading part } of this vulnerability) may still be vulnerable to the latter problem } (process ID re-use), if credentials aren't checked at signal delivery } time. I've got mixed feelings about credential checking. It doesn't eliminate inadvertent interference between processes with matching credentials when wraparound occurs, it doesn't cause a diagnostic to be returned if something bogus is done with F_SETOWN, and there may be cases where someone wants to use several cooperating processes with different credentials but sharing the same socket (though I really can't think of any and it looks like the patch allows this to work if root does the F_SETOWN). IMHO, the change to disable signal sending when the process or process group disappears should definitely be implemented. It increases security, there is no loss of functionality, and there is likely to be increased performance. The session and/or the credential checks should probably be implemented. Both of these limit functionality to some extent, but not enough to outweigh the increased security. Something else to consider is whether it makes sense to only send the signal to processes that have the object open. } Unfortunately, the log device is normally accessible by users, and can be } used to perform the same attack as sockets allow. It's also worth noting } that the interface that allows programs to set the process to receive } notification of I/O on the log device renders the legitimate purpose of } this facility totally unreliable; unrelated programs can seize control of } the asynchronous I/O notification on the log device, causing programs that } rely on it to fail. The provided patches do not attempt to resolve this } problem. In the case of the log device, F_SETOWN should probably be limited to root. --- Truck From owner-freebsd-security Tue Sep 16 20:49:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA10883 for security-outgoing; Tue, 16 Sep 1997 20:49:37 -0700 (PDT) Received: from silence.secnet.com (silence.secnet.com [199.185.231.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA10760 for ; Tue, 16 Sep 1997 20:47:48 -0700 (PDT) From: tqbf@silence.secnet.com Received: from localhost (tqbf@localhost) by silence.secnet.com (8.8.5/secnet) with SMTP id VAA01406; Tue, 16 Sep 1997 21:55:40 -0600 (MDT) Date: Tue, 16 Sep 1997 21:55:40 -0600 (MDT) To: Don Lewis cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-Reply-To: <199709170335.UAA26150@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Don Lewis wrote: > Should the argument to F_SETOWN undergo similar checks as the argument to > tcsetpgrp()? I don't think it makes sense to allow F_SETOWN to enable It does. Note that F_SETOWN is literally a generic-file-descriptor wrapper around TIOCSPGRP (check out the source), as well. > I think a better cure for the wraparound problem is to solve it the same > was as it is handled for controlling terminals. When the process group The terminal code deals with pointers to proc structures, and the generic device code deals with indexes into the process table; this is the reason credential checking was added. > process group and it no longer can send signals. This would have to be > extended to handle either processes or process groups for F_SETOWN. This Can you explain how this is a security-relevant proposal? The fix we've provided is addressed at a very specific problem; it wasn't anyone's intentions to change expected semantics, as you appear to suggest. > I've got mixed feelings about credential checking. It doesn't eliminate > inadvertent interference between processes with matching credentials when This would appear to be a general programming concern, and not a security issue. > bogus is done with F_SETOWN, and there may be cases where someone wants to > use several cooperating processes with different credentials but sharing > the same socket (though I really can't think of any and it looks like the If you could point out a specific instance in the code distributed with FreeBSD, it'd be helpful (to clarify your meaning here). > IMHO, the change to disable signal sending when the process or process group > disappears should definitely be implemented. It increases security, there > is no loss of functionality, and there is likely to be increased performance. How does this increase security in the presence of strict credential checking at signal delivery (a la csignal())? > Something else to consider is whether it makes sense to only send the signal > to processes that have the object open. Given that this is not an established semantic and it isn't documented anywhere, I think this might not be the most appropriate forum within which to suggest such a change. Neh? > In the case of the log device, F_SETOWN should probably be limited to > root. In the case of the log device, F_SETOWN should be eliminated. Special-cases inside the 4.4BSD kernel have been a fairly consistant source of problems, have they not? (Reference init(8)). ---------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ---------------------------------------------------------------------- "mmm... sacrilicious..." From owner-freebsd-security Tue Sep 16 21:58:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14982 for security-outgoing; Tue, 16 Sep 1997 21:58:46 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14972 for ; Tue, 16 Sep 1997 21:58:41 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id VAA00639; Tue, 16 Sep 1997 21:57:21 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id VAA00809; Tue, 16 Sep 1997 21:57:20 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA26232; Tue, 16 Sep 1997 21:57:18 -0700 (PDT) From: Don Lewis Message-Id: <199709170457.VAA26232@salsa.gv.tsc.tdk.com> Date: Tue, 16 Sep 1997 21:57:18 -0700 In-Reply-To: tqbf@silence.secnet.com "Re: OpenBSD Security Advisory: BSD I/O Signals" (Sep 16, 9:55pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: tqbf@silence.secnet.com, Don Lewis Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 16, 9:55pm, tqbf@silence.secnet.com wrote: } Subject: Re: OpenBSD Security Advisory: BSD I/O Signals } } On Tue, 16 Sep 1997, Don Lewis wrote: } } > Should the argument to F_SETOWN undergo similar checks as the argument to } > tcsetpgrp()? I don't think it makes sense to allow F_SETOWN to enable } } It does. Note that F_SETOWN is literally a generic-file-descriptor wrapper } around TIOCSPGRP (check out the source), as well. Not in the case of sockets. If you do F_SETOWN on a socket, the kernel blindly accepts whatever process or group ID that you supply with no further checking. } > I think a better cure for the wraparound problem is to solve it the same } > was as it is handled for controlling terminals. When the process group } } The terminal code deals with pointers to proc structures, and the generic } device code deals with indexes into the process table; this is the reason } credential checking was added. The terminal code actually deals with a pointer to a process group structure, which points to a list of processes. I think the generic device code should do the same (with the added complications that the generic device code must allow individual processes to be specified, and process or process group may have multiple SIGIO sources). } > process group and it no longer can send signals. This would have to be } > extended to handle either processes or process groups for F_SETOWN. This } } Can you explain how this is a security-relevant proposal? It totally eliminates the wraparound problem. } The fix we've } provided is addressed at a very specific problem; it wasn't anyone's } intentions to change expected semantics, as you appear to suggest. It reduces the functionality somewhat. I have doubts as to whether anyone "expects" that functionality or would find it useful. } > I've got mixed feelings about credential checking. It doesn't eliminate } > inadvertent interference between processes with matching credentials when } } This would appear to be a general programming concern, and not a security } issue. It mostly is a general programming concern, but it can prevent apparently random things from happening. Now this is a stretch, but what if an attacker subverted a root owned process to to a F_SETOWN, change uid to some harmless user, and exec /bin/sh? Various unlucky processes would receive SIGIO signals, but no matter what you ran ktrace on, you wouldn't be able to find their sender. } > bogus is done with F_SETOWN, and there may be cases where someone wants to } > use several cooperating processes with different credentials but sharing } > the same socket (though I really can't think of any and it looks like the } } If you could point out a specific instance in the code distributed with } FreeBSD, it'd be helpful (to clarify your meaning here). I seriously doubt there is any part of FreeBSD that uses the removed functionality. It's just that someone might find potentially find it useful ... } > IMHO, the change to disable signal sending when the process or process group } > disappears should definitely be implemented. It increases security, there } > is no loss of functionality, and there is likely to be increased performance. } } How does this increase security in the presence of strict credential } checking at signal delivery (a la csignal())? Innocent processes won't receive SIGIO even though they are unlucky enough to have a wrapped process ID, even though they have the same credentials as the process that did the F_SETOWN. Reliability is part of security ... } > Something else to consider is whether it makes sense to only send the signal } > to processes that have the object open. } } Given that this is not an established semantic and it isn't documented } anywhere, I think this might not be the most appropriate forum within } which to suggest such a change. Neh? It's another part of the big picture. It would increase security by limiting the processes that could be attacked and the functionality removed is probably slight. The downside would be the code bloat. } > In the case of the log device, F_SETOWN should probably be limited to } > root. } } In the case of the log device, F_SETOWN should be eliminated. Even better. --- Truck From owner-freebsd-security Tue Sep 16 22:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15480 for security-outgoing; Tue, 16 Sep 1997 22:07:06 -0700 (PDT) Received: from silence.secnet.com (silence.secnet.com [199.185.231.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15463 for ; Tue, 16 Sep 1997 22:06:26 -0700 (PDT) From: tqbf@silence.secnet.com Received: from localhost (tqbf@localhost) by silence.secnet.com (8.8.5/secnet) with SMTP id XAA01586; Tue, 16 Sep 1997 23:15:07 -0600 (MDT) Date: Tue, 16 Sep 1997 23:15:07 -0600 (MDT) To: Don Lewis cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals In-Reply-To: <199709170457.VAA26232@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Don Lewis wrote: > Not in the case of sockets. If you do F_SETOWN on a socket, the kernel > blindly accepts whatever process or group ID that you supply with no > further checking. You're saying that, after the OpenBSD patch, arbitrary processes can continue to SIGIO/SIGURG arbitrary other processes? > } Can you explain how this is a security-relevant proposal? > It totally eliminates the wraparound problem. As does credential checking at signal delivery. > random things from happening. Now this is a stretch, but what if an > attacker subverted a root owned process to to a F_SETOWN, change uid to The hole would be in the program that allowed an attacker to gain root access to fcntl, and there's not much you can do in the kernel to prevent the general case of this from remaining true. > to have a wrapped process ID, even though they have the same credentials > as the process that did the F_SETOWN. Reliability is part of security ... If the process has the exact same credentials, how is this a security issue? I think we're reaching a bit here. ---------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ---------------------------------------------------------------------- "mmm... sacrilicious..." From owner-freebsd-security Tue Sep 16 22:31:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17038 for security-outgoing; Tue, 16 Sep 1997 22:31:05 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17031 for ; Tue, 16 Sep 1997 22:31:02 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id WAA01049; Tue, 16 Sep 1997 22:30:21 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA01262; Tue, 16 Sep 1997 22:30:19 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA26272; Tue, 16 Sep 1997 22:30:18 -0700 (PDT) From: Don Lewis Message-Id: <199709170530.WAA26272@salsa.gv.tsc.tdk.com> Date: Tue, 16 Sep 1997 22:30:18 -0700 In-Reply-To: tqbf@silence.secnet.com "Re: OpenBSD Security Advisory: BSD I/O Signals" (Sep 16, 11:15pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: tqbf@silence.secnet.com, Don Lewis Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 16, 11:15pm, tqbf@silence.secnet.com wrote: } Subject: Re: OpenBSD Security Advisory: BSD I/O Signals } } On Tue, 16 Sep 1997, Don Lewis wrote: } } > Not in the case of sockets. If you do F_SETOWN on a socket, the kernel } > blindly accepts whatever process or group ID that you supply with no } > further checking. } } You're saying that, after the OpenBSD patch, arbitrary processes can } continue to SIGIO/SIGURG arbitrary other processes? Not totally arbitrary, the patch limits the victims to those that pass the credential test. } > } Can you explain how this is a security-relevant proposal? } > It totally eliminates the wraparound problem. } } As does credential checking at signal delivery. Only for those processes with different credentials. } > random things from happening. Now this is a stretch, but what if an } > attacker subverted a root owned process to to a F_SETOWN, change uid to } } The hole would be in the program that allowed an attacker to gain root } access to fcntl, and there's not much you can do in the kernel to prevent } the general case of this from remaining true. Generally if root can be subverted to do F_SETOWN, you're probably in a lot deeper trouble, but this does the door open to a weak but very stealthy attack. Instead of generally trashing things, an attacker could just make the system work slightly out of kilter and they don't even to keep the root process running which might raise suspicions. The attacker only needs to run an innocent looking process to keep the socket open. This situation could also occur by accident. All it takes is a root process that uses F_SETOWN and then forks a child which inherits the fd. If the parent process happens to die, the signals will get delivered to whatever processes are assigned the old ID of the parent. } > to have a wrapped process ID, even though they have the same credentials } > as the process that did the F_SETOWN. Reliability is part of security ... } } If the process has the exact same credentials, how is this a security } issue? I think we're reaching a bit here. ... or any process if root did the F_SETOWN. I agree that this is reaching a bit. --- Truck From owner-freebsd-security Tue Sep 16 22:49:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA18344 for security-outgoing; Tue, 16 Sep 1997 22:49:30 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA18332 for ; Tue, 16 Sep 1997 22:49:25 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id WAA01109; Tue, 16 Sep 1997 22:49:00 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA01558; Tue, 16 Sep 1997 22:48:59 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA26312; Tue, 16 Sep 1997 22:48:57 -0700 (PDT) From: Don Lewis Message-Id: <199709170548.WAA26312@salsa.gv.tsc.tdk.com> Date: Tue, 16 Sep 1997 22:48:57 -0700 In-Reply-To: tqbf@silence.secnet.com "Re: OpenBSD Security Advisory: BSD I/O Signals" (Sep 16, 11:15pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: tqbf@silence.secnet.com, Don Lewis Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 16, 11:15pm, tqbf@silence.secnet.com wrote: } Subject: Re: OpenBSD Security Advisory: BSD I/O Signals } } > random things from happening. Now this is a stretch, but what if an } > attacker subverted a root owned process to to a F_SETOWN, change uid to } } The hole would be in the program that allowed an attacker to gain root } access to fcntl, and there's not much you can do in the kernel to prevent } the general case of this from remaining true. I just found an exploit, but it's pretty weak. You can use it to send signals to processes that you don't own, but you can't choose the PID. Ftpd does a F_SETOWN on its control socket before it does authentication, which means that the credentials stashed away by F_SETOWN are root. If you log in as a normal user and you do an "ls -lR /" or something that takes a long time, you can "kill -STOP" the ls process, and kill ftpd entirely. The "ls" process will keep the control socket open (its connected to stdin), so whenever a process gets the old PID of ftpd, you can send it a SIGURG. A tiny hole, but it's there. --- Truck From owner-freebsd-security Wed Sep 17 09:05:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20785 for security-outgoing; Wed, 17 Sep 1997 09:05:22 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20736 for ; Wed, 17 Sep 1997 09:05:05 -0700 (PDT) Received: (qmail 15538 invoked by uid 1000); 17 Sep 1997 16:05:26 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Resent-Date: Wed, 17 Sep 1997 17:31:27 +0200 (MET-DST) Resent-Message-Id: Resent-From: Christian Hudon Resent-To: security@debian.org Date: Wed, 17 Sep 1997 09:05:26 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-security@freebsd.org Subject: FW: CERT Advisory CA-97.23 - rdist (fwd) Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I know we have a (much) superior O/S, but it never hurts to ask. Right? Simon ----- Forwarded Message ----: ----- Date: Wed, 17 Sep 1997 17:31:27 +0200 (MET-DST) From: Christian Hudon To: security@debian.org Subject: CERT Advisory CA-97.23 - rdist (fwd) Are we vulnerable to that one? Christian ---------- Forwarded message ---------- Date: Tue, 16 Sep 1997 14:26:13 -0500 From: Aleph One Reply-To: cert-advisory-request@cert.org To: BUGTRAQ@NETSPACE.ORG Subject: CERT Advisory CA-97.23 - rdist -----BEGIN PGP SIGNED MESSAGE----- ============================================================================ = CERT* Advisory CA-97.23 Original issue date: September 16, 1997 Last revised: -- Topic: Buffer Overflow Problem in rdist - ---------------------------------------------------------------------------- - The CERT Coordination Center has received reports of a vulnerability in rdist that enables anyone with access to a local account to gain root privileges. This is not the same vulnerability as the one discussed in CA-96.14. Section III.A contains instructions on how to determine if your site is vulnerable. If your implementation of rdist is vulnerable, the CERT/CC team encourages you to follow your vendor's instructions (Sec. III.B and Appendix A) or install a freely available version of the rdist program that is not installed as set-user-id root and is, therefore, not susceptible to the exploitation described in this advisory (Sec. III.C). For information on the earlier problem with rdist, see ftp://info.cert.org/pub/cert_advisories/CA-96.14.rdist_vul We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. - ---------------------------------------------------------------------------- - I. Description The rdist program is a UNIX Operating System utility used to distribute files from one host to another. On some systems, rdist opens network connections using a privileged port as the source port. This requires root privileges, and to attain these privileges rdist on such systems is installed set-user-id root. A new vulnerability has been found in some set-user-id root implementations of rdist. The vulnerability lies in the function expstr(), where macros supplied as arguments are expanded using sprintf(). It is possible to overwrite stack frames and call specially pre-crafted native machine code. If the appropriate machine code is supplied, an attacker can execute arbitrary programs (such as the shell) with set-user-id root privileges. Note that this vulnerability is distinct from that discussed in CERT advisory CA-96.14. II. Impact On systems with a vulnerable copy of rdist, anyone with access to a local account can gain root access. III. Solution We urge you to follow the steps in Section A to determine if your system is vulnerable and, if it is, to turn off rdist while you decide how to proceed. If your system is vulnerable and you need the functionality that rdist provides, you should install a vendor patch (Section B). Until you can do so, you may want to use a freely available version of rdist that does not need to be installed as set-user-id root and is, therefore, not susceptible to the exploitation described in this advisory (Section C). A. How to check for set-user-id root versions of rdist To find set-user-id root versions of rdist and to disable the programs that are possibly vulnerable, use the following find command or a variant. Consult your local system documentation to determine how to tailor the find program on your system. You will need to run the find command on each system you maintain because the command examines files on the local disk only. Substitute the names of your local file systems for FILE_SYSTEM_NAMES in the example. Example local file system names are /, /usr, and /var. You must do this as root. Note that this is one long command, though we have separated it onto three lines using backslashes. find FILE_SYSTEM_NAMES -xdev -type f -user root \ -name '*rdist*' -perm -04000 -exec ls -l '{}' \; \ -ok chmod 0500 '{}' \; This command will find all files on a system that - are only in the file system you name (FILE_SYSTEM_NAMES -xdev) - are regular files (-type f) - are owned by root (-user root) - have "rdist" as a component of the name (-name '*rdist*') - are setuid (-perm -04000) Once found, those files will - have their names and details printed (-exec ls -l '{}') - have the setuid mode removed (making the file available only to root) but only if you type `y' in response to the prompt (-ok chmod 0500 '{}' \;) B. Obtain and install the appropriate patch Below is a list of vendors who have provided information for this advisory. Details are in Appendix A, and we will update the appendix as we receive more information. Berkeley Software Design, Inc. (BSDI) Digital Equipment Corp. FreeBSD, Inc. Hewlett-Packard Company IBM Corporation NEC Corporation The Santa Cruz Operation, Inc. (SCO) Siemens-Nixdorf Silicon Graphics Inc. (SGI) Sun Microsystems, Inc. If your vendor's name is not on this list, please contact the vendor directly. C. If you need the functionality that rdist provides but a patched version is not yet available from your vendor, consider installing rdist-6.1.3, which is freely available from ftp://usc.edu/pub/rdist/rdist-6.1.3.tar.gz MD5 (rdist-6.1.3.tar.gz) = 8a76b880b023c5e648b7cb77b9608b9f The README file in the distribution explains how to configure and install this version of rdist. We recommend that you configure this version of rdist to use rsh instead of rcmd. Here is the relevant text from the README: By default rdist uses rsh(1c) to make connections to remote hosts. This has the advantage that rdist does not need to be setuid to "root". This eliminates most potential security holes. It has the disadvantage that it takes slightly more time for rdist to connect to a remote host due to the added overhead of doing a fork() and then running the rsh(1c) command. Some sites with sufficient expertise use the ssh program in conjunction with rdist, instead of using rcmd or rsh. If you have the expertise, you may want to implement this configuration. For further details on this option see "Ssh (Secure Shell) FAQ - Frequently asked questions," Section 4.4, "Can I use rdist with ssh?" It is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq-4.html For details on how to obtain ssh, see FAQ Section 3.4, "Where can I obtain ssh?" This section can be found in http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq-3.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) ===================================== BSDI shipped a patch for this for our 2.1 release (U210-018) when the original Bugtraq advisory was released. The 3.0 version of rdist is not vulnerable and in fact is no longer even setuid. Digital Equipment Corp. ======================= This reported problem is not present for Digital's ULTRIX or Digital UNIX Operating Systems Software. DIGITAL EQUIPMENT CORPORATION ----------------------------- FreeBSD, Inc. ============= 2.1.0 is vulnerable. 2.1.5, 2.1.6 and 2.1.7 are and 2.1-stable are not. In any case, upgrading to 2.1.7 or even better, 2.1-stable should be considered. If there is demand, we'll release a patch for 2.1.0 All 2.2 releases, 2.2-stable and FreeBSD-current are not vulnerable. Hewlett-Packard Company ======================= HP is -not- vulnerable; the problem didn't exist in 9.X, and has been fixed in 10.X with Security Bulletin #36 (HPSBUX9608-036) last year. Patch numbers change frequently because of cumulative patching, so please check current patch ID information either by bulletin or by platform/release at our HP Electronic Support Center in the "Security Patch Matrix," which is updated every 24 hours. 1) From your Web browser, access the URL: http://us-support.external.hp.com (US,Canada,Asia-Pacific, and Latin-America) http://europe-support.external.hp.com (Europe) 2) On the HP Electronic Support Center main screen, select the hyperlink "Support Information Digests". 3) On the "Welcome to HP's Support Information Digests" screen, under the heading "Register Now", select the appropriate hyperlink "Americas and Asia-Pacific", or "Europe". 4) On the "New User Registration" screen, fill in the fields for the User Information and Password and then select the button labeled "Submit New User". 5) On the "User ID Assigned" screen, select the hyperlink "Support Information Digests". **Note what your assigned user ID and password are for future reference. 6) You should now be on the "HP Support Information Digests Main" screen. You might want to verify that your email address is correct as displayed on the screen. From this screen, you may also view/subscribe to the digests, including the security bulletins digest. To get a patch matrix of current HP-UX and BLS security patches referenced by either Security Bulletin or Platform/OS, click on following screens in order: Technical Knowledge Database Browse the HP Security Bulletins Archive HP-UX Security Patch Matrix IBM Corporation =============== All versions of AIX are vulnerable to this buffer overflow. There is no 3.2 fix. It is recommended that 3.2 customers upgrade to a higher level. The following APARs will be available for AIX version 4 soon. AIX 3.2: upgrade to 4.1.5 or higher AIX 4.1: IX70876 AIX 4.2: IX70875 To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. NEC Corporation =============== The following systems are NOT affected by this vulnerability: UX/4800 UX/4800(64) EWS-UX/V(Rel4.2MP) EWS-UX/V(Rel4.2) UP-UX/V(Rel4.2MP) To report a new vulnerability, contact . The Santa Cruz Operation, Inc. (SCO) ==================================== SCO has determined that the following SCO operating systems are not vulnerable: - SCO CMW+ 3.0 - SCO Open Desktop/Open Server 3.0 - SCO OpenServer 5.0 - SCO UnixWare 2.1 Siemens-Nixdorf Informationssysteme AG ====================================== Siemens-Nixdorf does not ship rdist. Silicon Graphics Inc. (SGI) =========================== At this time, Silicon Graphics does not have any public information for the rdist buffer overflow issue. Silicon Graphics has communicated with CERT/CC and other external security parties and is actively investigating this issue. When more Silicon Graphics information (including any possible patches) is available for release, that information will be released via the SGI security mailing list, wiretap. For subscribing to the wiretap mailing list and other SGI security related information, please refer to the Silicon Graphics Security Headquarters website located at: http://www.sgi.com/Support/security/security.html Sun Microsystems, Inc. ====================== We are producing patches. - ---------------------------------------------------------------------------- - The CERT Coordination Center thanks Hiroshi Nakano of Ryukoku University, Japan for reporting this problem. We also thank Wolfgang Ley of DFN-CERT for his assistance with the Solutions section of the advisory. - ---------------------------------------------------------------------------- - If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/). CERT/CC Contact Information - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. *CERT is registered in the U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.23.rdist http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNB6ULXVP+x0t4w7BAQF7OgP9FBPOVv0sieagN7Qpbt6nykgKYd8yvi6x Tp4vdUsFEZBjyO8jA3eSyBpjcOBouhZhpCnaGtinZoCmYV+Mks/I4OnrVTyDMtmH DiDmGtzNwAMdAPn49bAgyGQsObUJ9v6hnHl34JbylJJ2h471AltdeoBtbrxwdE6d 4iv8mwfbQ5M= =QTr5 -----END PGP SIGNATURE----- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to debian-private-request@lists.debian.org . Trouble? e-mail to templin@bucknell.edu . --------------End of forwarded message------------------------- --- Sincerely Yours, (Sent on 17-Sep-97, 08:51:44 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-security Wed Sep 17 09:20:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22045 for security-outgoing; Wed, 17 Sep 1997 09:20:25 -0700 (PDT) Received: from login.bigblue.no (root@login.bigblue.no [194.19.68.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22040 for ; Wed, 17 Sep 1997 09:20:19 -0700 (PDT) Received: from eagle.bigblue.no (eagle.bigblue.no [194.19.68.13]) by login.bigblue.no (8.8.7/8.8.5) with SMTP id SAA25313 for ; Wed, 17 Sep 1997 18:20:15 +0200 (MET DST) Message-Id: <199709171620.SAA25313@login.bigblue.no> From: "Frode Nordahl" To: "freebsd-security@freebsd.org" Date: Wed, 17 Sep 97 18:20:13 +0100 Reply-To: "Frode Nordahl" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: schg flag... Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! schg is a good flag to have for security on certain files/binaries, but if the flag can be turned of as easilly as running chflags noschg, the flag is pretty useless. People that want to modify such files most likelly allready have access enough to the system to run chflags. I thought that the schg flag was only to be modified if the system was running in some other mode than standard multiuser...? _____________________________________________________________ Frode Nordahl | P.B. 2509 Solli | Tel +47 22 20 47 18 Teknisk ansvarlig | 0202 Oslo | Fax +47 22 20 39 19 Computer Tjenester AS | Norway | froden@bigblue.no From owner-freebsd-security Wed Sep 17 09:45:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA23953 for security-outgoing; Wed, 17 Sep 1997 09:45:45 -0700 (PDT) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA23945 for ; Wed, 17 Sep 1997 09:45:41 -0700 (PDT) Received: from cardinal.fsl.noaa.gov (daemon@cardinal.fsl.noaa.gov [137.75.60.101]) by gatekeeper.fsl.noaa.gov (8.8.5/8.8.5) with ESMTP id QAA28819; Wed, 17 Sep 1997 16:45:32 GMT Received: from fsl.noaa.gov (auk.fsl.noaa.gov) by cardinal.fsl.noaa.gov with ESMTP (1.40.112.3/16.2) id AA208614732; Wed, 17 Sep 1997 16:45:32 GMT Message-Id: <3420092B.7B59AA48@fsl.noaa.gov> Date: Wed, 17 Sep 1997 10:45:31 -0600 From: Sean Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 4.02b7 [en] (X11; I; HP-UX B.10.20 9000/725) Mime-Version: 1.0 To: Frode Nordahl , security@freebsd.org Subject: Re: schg flag... References: <199709171620.SAA25313@login.bigblue.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The schg flag can't be changed when the system is running in securelevel 1 or 2. See init(1) for more details. According to that man page, the securelevel is usually set in /etc/rc during bootup. A quick grep through /etc/* doesn't contain any reference to securelevel, though. You could probably add it yourself to your own rc files, but it'd be nice if there were an /etc/rc.conf entry for it. --Sean From owner-freebsd-security Wed Sep 17 09:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24596 for security-outgoing; Wed, 17 Sep 1997 09:55:31 -0700 (PDT) Received: from login.bigblue.no (root@login.bigblue.no [194.19.68.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24585 for ; Wed, 17 Sep 1997 09:55:25 -0700 (PDT) Received: from eagle.bigblue.no (eagle.bigblue.no [194.19.68.13]) by login.bigblue.no (8.8.7/8.8.5) with SMTP id SAA26869; Wed, 17 Sep 1997 18:55:09 +0200 (MET DST) Message-Id: <199709171655.SAA26869@login.bigblue.no> From: "Frode Nordahl" To: "Sean Kelly" Cc: "freebsd-security@freebsd.org" Date: Wed, 17 Sep 97 18:55:07 +0100 Reply-To: "Frode Nordahl" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: schg flag... Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997 10:45:31 -0600, Sean Kelly wrote: >The schg flag can't be changed when the system is running in securelevel >1 or 2. See init(1) for more details. > >According to that man page, the securelevel is usually set in /etc/rc >during bootup. A quick grep through /etc/* doesn't contain any >reference to securelevel, though. You could probably add it yourself to >your own rc files, but it'd be nice if there were an /etc/rc.conf entry >for it. Ok... Well then's a question, why is FreeBSD's standard mode to run in leve -1? Isn't that a bit suicidal? _____________________________________________________________ Frode Nordahl | P.B. 2509 Solli | Tel +47 22 20 47 18 Teknisk ansvarlig | 0202 Oslo | Fax +47 22 20 39 19 Computer Tjenester AS | Norway | froden@bigblue.no From owner-freebsd-security Wed Sep 17 10:33:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26853 for security-outgoing; Wed, 17 Sep 1997 10:33:39 -0700 (PDT) Received: from fang.cs.sunyit.edu (perlsta@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26846 for ; Wed, 17 Sep 1997 10:33:29 -0700 (PDT) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) with SMTP id RAA25758; Wed, 17 Sep 1997 17:33:33 GMT Date: Wed, 17 Sep 1997 17:33:33 +0000 (GMT) From: Alfred Perlstein To: Simon Shapiro cc: freebsd-security@FreeBSD.ORG, Christian Hudon , security@debian.org Subject: Re: FW: CERT Advisory CA-97.23 - rdist (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk last i checked rdist is NOT setuid on FreeBSD no hole! On Wed, 17 Sep 1997, Simon Shapiro wrote: > I know we have a (much) superior O/S, but it never hurts to ask. Right? > > Simon > > ----- Forwarded Message ----: > ----- > > Date: Wed, 17 Sep 1997 17:31:27 +0200 (MET-DST) > From: Christian Hudon > To: security@debian.org > Subject: CERT Advisory CA-97.23 - rdist (fwd) > > Are we vulnerable to that one? > > Christian > > ---------- Forwarded message ---------- > Date: Tue, 16 Sep 1997 14:26:13 -0500 > From: Aleph One > Reply-To: cert-advisory-request@cert.org > To: BUGTRAQ@NETSPACE.ORG > Subject: CERT Advisory CA-97.23 - rdist > > -----BEGIN PGP SIGNED MESSAGE----- > > ============================================================================ > = > CERT* Advisory CA-97.23 > Original issue date: September 16, 1997 > Last revised: -- > > Topic: Buffer Overflow Problem in rdist > - > ---------------------------------------------------------------------------- > - > > The CERT Coordination Center has received reports of a vulnerability in > rdist > that enables anyone with access to a local account to gain root privileges. > This is not the same vulnerability as the one discussed in CA-96.14. > > Section III.A contains instructions on how to determine if your site is > vulnerable. If your implementation of rdist is vulnerable, the CERT/CC team > encourages you to follow your vendor's instructions (Sec. III.B and Appendix > A) or install a freely available version of the rdist program that is not > installed as set-user-id root and is, therefore, not susceptible to the > exploitation described in this advisory (Sec. III.C). > > For information on the earlier problem with rdist, see > ftp://info.cert.org/pub/cert_advisories/CA-96.14.rdist_vul > > We will update this advisory as we receive additional information. > Please check our advisory files regularly for updates that relate to your > site. > > - > ---------------------------------------------------------------------------- > - > > I. Description > > The rdist program is a UNIX Operating System utility used to > distribute files from one host to another. On some systems, rdist > opens network connections using a privileged port as the source port. > This requires root privileges, and to attain these privileges rdist on > such systems is installed set-user-id root. > > A new vulnerability has been found in some set-user-id root > implementations of rdist. The vulnerability lies in the function > expstr(), where macros supplied as arguments are expanded using > sprintf(). It is possible to overwrite stack frames and call specially > pre-crafted native machine code. If the appropriate machine code is > supplied, an attacker can execute arbitrary programs (such as the > shell) with set-user-id root privileges. > > Note that this vulnerability is distinct from that discussed in CERT > advisory CA-96.14. > > > II. Impact > > On systems with a vulnerable copy of rdist, anyone with access to a > local account can gain root access. > > > III. Solution > > We urge you to follow the steps in Section A to determine if your > system is vulnerable and, if it is, to turn off rdist while you decide > how to proceed. > > If your system is vulnerable and you need the functionality that rdist > provides, you should install a vendor patch (Section B). Until you can > do so, you may want to use a freely available version of rdist that > does not need to be installed as set-user-id root and is, therefore, > not susceptible to the exploitation described in this advisory > (Section C). > > A. How to check for set-user-id root versions of rdist > > To find set-user-id root versions of rdist and to disable the > programs that are possibly vulnerable, use the following find > command or a variant. Consult your local system documentation to > determine how to tailor the find program on your system. > > You will need to run the find command on each system you maintain > because the command examines files on the local disk only. > Substitute the names of your local file systems for > FILE_SYSTEM_NAMES in the example. Example local file system names > are /, /usr, and /var. You must do this as root. > > Note that this is one long command, though we have separated > it onto three lines using backslashes. > > find FILE_SYSTEM_NAMES -xdev -type f -user root \ > -name '*rdist*' -perm -04000 -exec ls -l '{}' \; \ > -ok chmod 0500 '{}' \; > > This command will find all files on a system that > - are only in the file system you name (FILE_SYSTEM_NAMES -xdev) > - are regular files (-type f) > - are owned by root (-user root) > - have "rdist" as a component of the name (-name '*rdist*') > - are setuid (-perm -04000) > > Once found, those files will > - have their names and details printed (-exec ls -l '{}') > - have the setuid mode removed (making the file available > only to root) but only if you type `y' in response to the > prompt (-ok chmod 0500 '{}' \;) > > B. Obtain and install the appropriate patch > > Below is a list of vendors who have provided information for this > advisory. Details are in Appendix A, and we will update the appendix > as we receive more information. > > Berkeley Software Design, Inc. (BSDI) > Digital Equipment Corp. > FreeBSD, Inc. > Hewlett-Packard Company > IBM Corporation > NEC Corporation > The Santa Cruz Operation, Inc. (SCO) > Siemens-Nixdorf > Silicon Graphics Inc. (SGI) > Sun Microsystems, Inc. > > If your vendor's name is not on this list, please contact the > vendor directly. > > C. If you need the functionality that rdist provides but a patched > version is not yet available from your vendor, consider installing > rdist-6.1.3, which is freely available from > > ftp://usc.edu/pub/rdist/rdist-6.1.3.tar.gz > > MD5 (rdist-6.1.3.tar.gz) = 8a76b880b023c5e648b7cb77b9608b9f > > The README file in the distribution explains how to configure and > install this version of rdist. > > We recommend that you configure this version of rdist to use rsh > instead of rcmd. Here is the relevant text from the README: > > By default rdist uses rsh(1c) to make connections to remote > hosts. This has the advantage that rdist does not need to be > setuid to "root". This eliminates most potential security > holes. It has the disadvantage that it takes slightly more time > for rdist to connect to a remote host due to the added overhead > of doing a fork() and then running the rsh(1c) command. > > Some sites with sufficient expertise use the ssh program in > conjunction with rdist, instead of using rcmd or rsh. If you have > the expertise, you may want to implement this configuration. > > For further details on this option see "Ssh (Secure Shell) FAQ - > Frequently asked questions," Section 4.4, "Can I use rdist with > ssh?" > It is available from > > http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq-4.html > > For details on how to obtain ssh, see FAQ Section 3.4, "Where can I > obtain ssh?" This section can be found in > > http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq-3.html > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Appendix A - Vendor Information > > Below is a list of the vendors who have provided information for this > advisory. We will update this appendix as we receive additional information. > If you do not see your vendor's name, the CERT/CC did not hear from that > vendor. Please contact the vendor directly. > > > Berkeley Software Design, Inc. (BSDI) > ===================================== > BSDI shipped a patch for this for our 2.1 release (U210-018) when > the original Bugtraq advisory was released. The 3.0 version of > rdist is not vulnerable and in fact is no longer even setuid. > > > Digital Equipment Corp. > ======================= > This reported problem is not present for Digital's ULTRIX or Digital UNIX > Operating Systems Software. > > DIGITAL EQUIPMENT CORPORATION > ----------------------------- > > FreeBSD, Inc. > ============= > 2.1.0 is vulnerable. > 2.1.5, 2.1.6 and 2.1.7 are and 2.1-stable are not. In any case, upgrading > to 2.1.7 or even better, 2.1-stable should be considered. > If there is demand, we'll release a patch for 2.1.0 > > All 2.2 releases, 2.2-stable and FreeBSD-current are not vulnerable. > > > Hewlett-Packard Company > ======================= > HP is -not- vulnerable; the problem didn't exist in 9.X, and has been > fixed > in 10.X with Security Bulletin #36 (HPSBUX9608-036) last year. Patch > numbers change frequently because of cumulative patching, so please check > current patch ID information either by bulletin or by platform/release at > our HP Electronic Support Center in the "Security Patch Matrix," which is > updated every 24 hours. > > 1) From your Web browser, access the URL: > > http://us-support.external.hp.com (US,Canada,Asia-Pacific, > and Latin-America) > > http://europe-support.external.hp.com (Europe) > > 2) On the HP Electronic Support Center main screen, select the > hyperlink "Support Information Digests". > > > 3) On the "Welcome to HP's Support Information Digests" screen, > under the heading "Register Now", select the appropriate hyperlink > "Americas and Asia-Pacific", or "Europe". > > 4) On the "New User Registration" screen, fill in the fields > for the User Information and Password and then select the button > labeled "Submit New User". > > 5) On the "User ID Assigned" screen, select the hyperlink > "Support Information Digests". > > **Note what your assigned user ID and password are for future > reference. > > 6) You should now be on the "HP Support Information Digests Main" > screen. You might want to verify that your email address is > correct as displayed on the screen. From this screen, you may > also view/subscribe to the digests, including the security > bulletins digest. > > To get a patch matrix of current HP-UX and BLS security > patches referenced by either Security Bulletin or Platform/OS, > click on following screens in order: > Technical Knowledge Database > Browse the HP Security Bulletins Archive > HP-UX Security Patch Matrix > > > IBM Corporation > =============== > All versions of AIX are vulnerable to this buffer overflow. There is > no 3.2 fix. It is recommended that 3.2 customers upgrade to a higher > level. The following APARs will be available for AIX version 4 > soon. > > AIX 3.2: upgrade to 4.1.5 or higher > AIX 4.1: IX70876 > AIX 4.2: IX70875 > > To Order > -------- > APARs may be ordered using Electronic Fix Distribution (via FixDist) > or from the IBM Support Center. For more information on FixDist, > reference URL: > > http://service.software.ibm.com/aixsupport/ > > or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". > > IBM and AIX are registered trademarks of International Business Machines > Corporation. > > > NEC Corporation > =============== > The following systems are NOT affected by this vulnerability: > > UX/4800 > UX/4800(64) > EWS-UX/V(Rel4.2MP) > EWS-UX/V(Rel4.2) > UP-UX/V(Rel4.2MP) > > To report a new vulnerability, contact . > > > The Santa Cruz Operation, Inc. (SCO) > ==================================== > SCO has determined that the following SCO operating systems are > not vulnerable: > > - SCO CMW+ 3.0 > - SCO Open Desktop/Open Server 3.0 > - SCO OpenServer 5.0 > - SCO UnixWare 2.1 > > > Siemens-Nixdorf Informationssysteme AG > ====================================== > Siemens-Nixdorf does not ship rdist. > > > Silicon Graphics Inc. (SGI) > =========================== > At this time, Silicon Graphics does not have any public information for > the > rdist buffer overflow issue. Silicon Graphics has communicated with > CERT/CC > and other external security parties and is actively investigating this > issue. When more Silicon Graphics information (including any possible > patches) is available for release, that information will be released via > the > SGI security mailing list, wiretap. > > For subscribing to the wiretap mailing list and other SGI security related > information, please refer to the Silicon Graphics Security Headquarters > website located at: > > http://www.sgi.com/Support/security/security.html > > > Sun Microsystems, Inc. > ====================== > We are producing patches. > > - > ---------------------------------------------------------------------------- > - > > The CERT Coordination Center thanks Hiroshi Nakano of Ryukoku University, > Japan for reporting this problem. We also thank Wolfgang Ley of DFN-CERT > for his assistance with the Solutions section of the advisory. > > - > ---------------------------------------------------------------------------- > - > > If you believe that your system has been compromised, contact the CERT > Coordination Center or your representative in the Forum of Incident Response > and Security Teams (see http://www.first.org/team-info/). > > > CERT/CC Contact Information > - ---------------------------- > Email cert@cert.org > > Phone +1 412-268-7090 (24-hour hotline) > CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) > and are on call for emergencies during other hours. > > Fax +1 412-268-6989 > > Postal address > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > USA > > Using encryption > We strongly urge you to encrypt sensitive information sent by email. We > can > support a shared DES key or PGP. Contact the CERT/CC for more > information. > Location of CERT PGP key > ftp://info.cert.org/pub/CERT_PGP.key > > Getting security information > CERT publications and other security information are available from > http://www.cert.org/ > ftp://info.cert.org/pub/ > > CERT advisories and bulletins are also posted on the USENET newsgroup > comp.security.announce > > To be added to our mailing list for advisories and bulletins, send > email to > cert-advisory-request@cert.org > In the subject line, type > SUBSCRIBE your-email-address > > - > --------------------------------------------------------------------------- > Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers, > and sponsorship information can be found in > http://www.cert.org/legal_stuff.html and > ftp://info.cert.org/pub/legal_stuff . > If you do not have FTP or web access, send mail to cert@cert.org with > "copyright" in the subject line. > > *CERT is registered in the U.S. Patent and Trademark Office. > > - > --------------------------------------------------------------------------- > > This file: ftp://info.cert.org/pub/cert_advisories/CA-97.23.rdist > http://www.cert.org > click on "CERT Advisories" > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Revision history > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBNB6ULXVP+x0t4w7BAQF7OgP9FBPOVv0sieagN7Qpbt6nykgKYd8yvi6x > Tp4vdUsFEZBjyO8jA3eSyBpjcOBouhZhpCnaGtinZoCmYV+Mks/I4OnrVTyDMtmH > DiDmGtzNwAMdAPn49bAgyGQsObUJ9v6hnHl34JbylJJ2h471AltdeoBtbrxwdE6d > 4iv8mwfbQ5M= > =QTr5 > -----END PGP SIGNATURE----- > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > debian-private-request@lists.debian.org . > Trouble? e-mail to templin@bucknell.edu . > > > --------------End of forwarded message------------------------- > > --- > > > Sincerely Yours, (Sent on 17-Sep-97, 08:51:44 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-security Wed Sep 17 11:14:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29359 for security-outgoing; Wed, 17 Sep 1997 11:14:43 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29354 for ; Wed, 17 Sep 1997 11:14:40 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA29341; Wed, 17 Sep 1997 12:14:32 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA07110; Wed, 17 Sep 1997 12:14:29 -0600 (MDT) Date: Wed, 17 Sep 1997 12:14:29 -0600 (MDT) Message-Id: <199709171814.MAA07110@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Simon Shapiro Cc: freebsd-security@freebsd.org Subject: Re: FW: CERT Advisory CA-97.23 - rdist (fwd) In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro writes: > I know we have a (much) superior O/S, but it never hurts to ask. Right? > > Simon Did you read the advisory? .... > B. Obtain and install the appropriate patch > > Below is a list of vendors who have provided information for this > advisory. Details are in Appendix A, and we will update the appendix > as we receive more information. > ... > FreeBSD, Inc. ... > FreeBSD, Inc. > ============= > 2.1.0 is vulnerable. > 2.1.5, 2.1.6 and 2.1.7 are and 2.1-stable are not. In any case, upgrading > to 2.1.7 or even better, 2.1-stable should be considered. > If there is demand, we'll release a patch for 2.1.0 > > All 2.2 releases, 2.2-stable and FreeBSD-current are not vulnerable. *Sheesh*, how more obvious can it be? Nate From owner-freebsd-security Wed Sep 17 11:52:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01965 for security-outgoing; Wed, 17 Sep 1997 11:52:46 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01951 for ; Wed, 17 Sep 1997 11:52:40 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id UAA07882; Wed, 17 Sep 1997 20:58:20 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709171858.UAA07882@ocean.campus.luth.se> Subject: Re: schg flag... In-Reply-To: <199709171655.SAA26869@login.bigblue.no> from Frode Nordahl at "Sep 17, 97 06:55:07 pm" To: froden@bigblue.no Date: Wed, 17 Sep 1997 20:58:19 +0200 (CEST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Frode Nordahl: > On Wed, 17 Sep 1997 10:45:31 -0600, Sean Kelly wrote: > > >The schg flag can't be changed when the system is running in securelevel > >1 or 2. See init(1) for more details. > > > >According to that man page, the securelevel is usually set in /etc/rc > >during bootup. A quick grep through /etc/* doesn't contain any > >reference to securelevel, though. You could probably add it yourself to > >your own rc files, but it'd be nice if there were an /etc/rc.conf entry > >for it. > > Ok... Well then's a question, why is FreeBSD's standard mode to run in > leve -1? Isn't that a bit suicidal? No, it's practical. Running at a higher securelevel just makes things harder for you. Compiling a new kernel, etc. Why bother making your computer a fortress when you really don't have much important data on it? It's just annoying to have to lower the drawbridge every time you wanna run out to pick a fresh apple. :-) Ofcourse, when you set up a server which actually contains data you can't afford to loose, or having someone unauthorised read, then you should probably raise the secure level. But most machines running FreeBSD are most likely just workstations, which can be wiped and reinstalled if anything really bad happens. Therefor that's the default. /Mikael From owner-freebsd-security Wed Sep 17 12:06:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02815 for security-outgoing; Wed, 17 Sep 1997 12:06:24 -0700 (PDT) Received: from login.bigblue.no (root@login.bigblue.no [194.19.68.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02808 for ; Wed, 17 Sep 1997 12:06:17 -0700 (PDT) Received: from eagle.bigblue.no (eagle.bigblue.no [194.19.68.13]) by login.bigblue.no (8.8.7/8.8.5) with SMTP id VAA01931; Wed, 17 Sep 1997 21:06:07 +0200 (MET DST) Message-Id: <199709171906.VAA01931@login.bigblue.no> From: "Frode Nordahl" To: "Mikael Karpberg" Cc: "freebsd-security@freebsd.org" Date: Wed, 17 Sep 97 21:06:04 +0100 Reply-To: "Frode Nordahl" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: schg flag... Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997 20:58:19 +0200 (CEST), Mikael Karpberg wrote: >> Ok... Well then's a question, why is FreeBSD's standard mode to run in >> leve -1? Isn't that a bit suicidal? > >No, it's practical. Running at a higher securelevel just makes things harder >for you. Compiling a new kernel, etc. Why bother making your computer a >fortress when you really don't have much important data on it? It's just >annoying to have to lower the drawbridge every time you wanna run out to >pick a fresh apple. :-) > >Ofcourse, when you set up a server which actually contains data you can't >afford to loose, or having someone unauthorised read, then you should >probably raise the secure level. But most machines running FreeBSD are >most likely just workstations, which can be wiped and reinstalled if >anything really bad happens. Therefor that's the default. I can understand that! I would really hate it if I had those limitations on my workstation, but the install program, or the rc.conf file should mention it somewhere. One of our FreeBSD boxes run as a user shell-account server. And with all of those "mad" users running arround, having some security is pretty nice. Okay, if something happends, we can allways reinstall, but that costs us time, money, and reputation. So the box is to be as secure as possible at any time. _____________________________________________________________ Frode Nordahl | P.B. 2509 Solli | Tel +47 22 20 47 18 Teknisk ansvarlig | 0202 Oslo | Fax +47 22 20 39 19 Computer Tjenester AS | Norway | froden@bigblue.no From owner-freebsd-security Wed Sep 17 12:38:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04651 for security-outgoing; Wed, 17 Sep 1997 12:38:21 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04646 for ; Wed, 17 Sep 1997 12:38:15 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA13007; Wed, 17 Sep 1997 15:37:20 -0400 (EDT) Date: Wed, 17 Sep 1997 15:37:17 -0400 (EDT) From: Brian Mitchell To: Frode Nordahl cc: "freebsd-security@freebsd.org" Subject: Re: schg flag... In-Reply-To: <199709171620.SAA25313@login.bigblue.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Frode Nordahl wrote: > Hello! > > schg is a good flag to have for security on certain files/binaries, but if the flag can be turned of as easilly as running > chflags noschg, the flag is pretty useless. set securelevel above the 'perm insecure' level, and this will not be the case. > > People that want to modify such files most likelly allready have access enough to the system to run chflags. > > I thought that the schg flag was only to be modified if the system was running in some other mode than standard > multiuser...? From owner-freebsd-security Wed Sep 17 14:07:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11424 for security-outgoing; Wed, 17 Sep 1997 14:07:35 -0700 (PDT) Received: from cyrus.watson.org (robert@AMALTHEA.RES.CMU.EDU [128.2.91.57]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11411 for ; Wed, 17 Sep 1997 14:07:26 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id RAA03135; Wed, 17 Sep 1997 17:04:40 -0400 (EDT) Date: Wed, 17 Sep 1997 17:04:40 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Sean Kelly cc: security@FreeBSD.ORG Subject: Re: schg flag... In-Reply-To: <3420092B.7B59AA48@fsl.noaa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Sean Kelly wrote: > The schg flag can't be changed when the system is running in securelevel > 1 or 2. See init(1) for more details. > > According to that man page, the securelevel is usually set in /etc/rc > during bootup. A quick grep through /etc/* doesn't contain any > reference to securelevel, though. You could probably add it yourself to > your own rc files, but it'd be nice if there were an /etc/rc.conf entry > for it. The man pages makes reference to the securemode being changed differently by init depending on its initial state: -- If the security level is initially -1, then init leaves it unchanged. Otherwise, init arranges to run the system 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 while single user, e.g., in the startup script /etc/rc, using sysctl(8). -- This seems to imply that perhaps a kernel configuration option could be used to set it initially to 0 instead of -1. So my question is this --- how does the appendonly flag interact with move, newsyslog, etc. Ideally, logged matieral could be added to, but never deleted. However, is this handled by inode, by open file, etc? If I set the appendonly flag on /var/log/messages, it will most likely work in the correct securelevel. If I do a mv messages messages.0, does it move it (only change to the directory reference, not to the file)? How does this work with hard links? If I create a hard link to a syschg'd file in /var/tmp, presumably it retains the same property. Can it no longer be removed by anyone, including superuser? Newsyslog assumes the ability to rename files, create new files, etc. Presumably newsyslog used with the append-only flag would be a bad thing. Also, if you're going to use rc/rc.conf/etc to set securelevel, you need to do a syschg on /etc/rc, /etc/rc.conf, /etc/rc.anythingelsethatrunsbeforerc.local, /bin/sh, the libraries it might or might not be linked against, sysctl itself, etc. Turning on securelevel can disuade people, but will not stop them if you do it wrong -- if all you need to do is reboot the machine to turn it off or set it as your please, this is undesirable. Similarly, every command run by rc is now suspect -- the [ evaluator, mount, ifconfig, etc. A kernel flag makes much more sense. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Wed Sep 17 15:49:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16579 for security-outgoing; Wed, 17 Sep 1997 15:49:48 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16571 for ; Wed, 17 Sep 1997 15:49:42 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id SAA13587; Wed, 17 Sep 1997 18:49:04 -0400 (EDT) Date: Wed, 17 Sep 1997 18:48:58 -0400 (EDT) From: Brian Mitchell To: Robert Watson cc: Sean Kelly , security@FreeBSD.ORG Subject: Re: schg flag... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Robert Watson wrote: > So my question is this --- how does the appendonly flag interact with > move, newsyslog, etc. Ideally, logged matieral could be added to, but > never deleted. However, is this handled by inode, by open file, etc? If > I set the appendonly flag on /var/log/messages, it will most likely work > in the correct securelevel. If I do a mv messages messages.0, does it > move it (only change to the directory reference, not to the file)? How no, mv doesnt work, neither does unlink: # cd /tmp # touch foo # chflags sappnd foo # mv foo bar mv: rename foo to bar: Operation not permitted # rm foo override rw-r--r-- root/bin sappnd for foo? y rm: foo: Operation not permitted > does this work with hard links? If I create a hard link to a syschg'd > file in /var/tmp, presumably it retains the same property. Can it no > longer be removed by anyone, including superuser? nor do hard links # ln foo bar ln: bar: Operation not permitted > > Newsyslog assumes the ability to rename files, create new files, etc. > Presumably newsyslog used with the append-only flag would be a bad thing. yes, it wouldnt work :) From owner-freebsd-security Thu Sep 18 00:05:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13542 for security-outgoing; Thu, 18 Sep 1997 00:05:04 -0700 (PDT) Received: from gatekeeper.lottery.co.at (gatekeeper.lottery.co.at [193.83.18.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA13524 for ; Thu, 18 Sep 1997 00:04:56 -0700 (PDT) Received: from mailgate.lottery.co.at by gatekeeper.lottery.co.at (5.65v4.0/1.1.8.2/24Aug95-0519PM) id AA15105; Thu, 18 Sep 1997 09:04:05 +0200 Received: from alolgm1.lottery.co.at by mailgate.lottery.co.at (5.65v4.0/1.1.8.2/11Oct95-0330PM) id AA22025; Thu, 18 Sep 1997 09:04:04 +0200 Received: by alolgm1.lottery.co.at with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BCC411.F075C770@alolgm1.lottery.co.at>; Thu, 18 Sep 1997 09:04:58 +0200 Message-Id: From: Sigart Wolfgang To: "'security@FreeBSD.ORG'" Subject: FTP compromise Date: Thu, 18 Sep 1997 09:04:56 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-security Thu Sep 18 03:43:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA27268 for security-outgoing; Thu, 18 Sep 1997 03:43:54 -0700 (PDT) Received: from egeo.unipg.it (egeo.unipg.it [141.250.1.4]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA27028 for ; Thu, 18 Sep 1997 03:41:27 -0700 (PDT) Received: by egeo.unipg.it (AIX 3.2/UCB 5.64/MH-1.09) id AA49053; Thu, 18 Sep 1997 12:16:58 +0200 From: sabatini@unipg.it (Giovanni Sabatini) Message-Id: <9709181016.AA49053@egeo.unipg.it> Subject: The IP Network Address Translator (NAT) To: freebsd-security@FreeBSD.ORG Date: Thu, 18 Sep 1997 12:16:58 +0200 (MDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I want to try the NAT (RFC 1631) software on my FreeBSD work station. Are there any public domain softwares for FreeBSD ? Thanks in advance. Giovanni Sabatini ---------------------- University of Perugia - Italy From owner-freebsd-security Thu Sep 18 05:44:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA03453 for security-outgoing; Thu, 18 Sep 1997 05:44:35 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA03446 for ; Thu, 18 Sep 1997 05:44:30 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id WAA11558; Thu, 18 Sep 1997 22:42:00 +1000 (EST) Date: Thu, 18 Sep 1997 22:41:58 +1000 (EST) From: "Daniel O'Callaghan" To: Giovanni Sabatini cc: freebsd-security@FreeBSD.ORG Subject: Re: The IP Network Address Translator (NAT) In-Reply-To: <9709181016.AA49053@egeo.unipg.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Giovanni Sabatini wrote: > Hello, > I want to try the NAT (RFC 1631) software on my FreeBSD work station. > Are there any public domain softwares for FreeBSD ? In 2.2.2: cd /usr/ports/net/natd ; make ; make install ; man natd In recent releng22 releases: man natd This belongs in freebsd-questions, not freebsd-security. Danny From owner-freebsd-security Thu Sep 18 06:35:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA05922 for security-outgoing; Thu, 18 Sep 1997 06:35:48 -0700 (PDT) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05911 for ; Thu, 18 Sep 1997 06:35:30 -0700 (PDT) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id HAA03194; Thu, 18 Sep 1997 07:38:34 -0600 (MDT) Date: Thu, 18 Sep 1997 07:38:34 -0600 (MDT) Message-Id: <199709181338.HAA03194@obie.softweyr.ml.org> From: Wes Peters To: Sigart Wolfgang CC: security@freebsd.org Subject: FTP compromise In-Reply-To: References: Reply-To: chat@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sigart Wolfgang writes: > Wow, an FTP compromise that causes empty email messages to be sent to the FreeBSD security list! That's innovative! ;^) Redirected to chat, where this will inevitably wind up belonging. -- "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 Thu Sep 18 07:10:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA07866 for security-outgoing; Thu, 18 Sep 1997 07:10:10 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA07854 for ; Thu, 18 Sep 1997 07:10:02 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id QAA05224; Thu, 18 Sep 1997 16:01:23 +0200 (MET DST) Date: Thu, 18 Sep 1997 16:01:23 +0200 (MET DST) Message-Id: <199709181401.QAA05224@bitbox.follo.net> From: Eivind Eklund To: sabatini@unipg.it (Giovanni Sabatini) CC: freebsd-security@FreeBSD.ORG In-reply-to: sabatini@unipg.it's message of Thu, 18 Sep 1997 12:16:58 +0200 (MDT) Subject: Re: The IP Network Address Translator (NAT) References: <9709181016.AA49053@egeo.unipg.it> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hello, > I want to try the NAT (RFC 1631) software on my FreeBSD work station. > Are there any public domain softwares for FreeBSD ? man natd man ppp Or you can check out http://www.srv.net/~cmott/ Eivind.