From owner-freebsd-security Sun Apr 28 00:28:07 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA13823 for security-outgoing; Sun, 28 Apr 1996 00:28:07 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA13747 Sun, 28 Apr 1996 00:27:48 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id QAA10885; Sun, 28 Apr 1996 16:56:45 +0930 From: Michael Smith Message-Id: <199604280726.QAA10885@genesis.atrad.adelaide.edu.au> Subject: Re: Simple SOCKS Daemon To: tlod@leverage.com (Thede Loder) Date: Sun, 28 Apr 1996 16:56:45 +0930 (CST) Cc: freebsd-isp@freebsd.org, freebsd-security@freebsd.org, freebsd-doc@freebsd.org In-Reply-To: from "Thede Loder" at Apr 27, 96 03:06:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thede Loder stands accused of saying: > > I have implemented a SOCKS version 4 server for FreeBSD. I will be porting > it to other platforms, but in the mean time, I'm looking for some feedback. Uhh, I have to ask: why? The normal SOCKS proxy server builds for FreeBSD just fine. If you have a version _5_ server, then you're talking. It appears that v5 can't be exported from the USA. Boo ITAR Boo! > -Thede Loder -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Sun Apr 28 07:22:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA01533 for security-outgoing; Sun, 28 Apr 1996 07:22:52 -0700 (PDT) Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.125.68.131]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA01454 for ; Sun, 28 Apr 1996 07:21:12 -0700 (PDT) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by burka.carrier.kiev.ua (Sendmail 8.who.cares/5) with ESMTP id RAA04925; Sun, 28 Apr 1996 17:18:22 +0300 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id QAA29114; Sun, 28 Apr 1996 16:59:16 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by acc0.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id RAA16277; Sun, 28 Apr 1996 17:10:13 +0300 (EET DST) Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id RAA21377; Sun, 28 Apr 1996 17:10:13 +0300 From: "Andrew V. Stesin" Message-Id: <199604281410.RAA21377@office.elvisti.kiev.ua> Subject: Q on using "netpipes" for firewall maintanance tasks To: firewalls@greatcircle.com, security@freebsd.org Date: Sun, 28 Apr 1996 17:10:12 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello people, I'm now in a search for safer but convenient rsh(1) replacement for some tasks of firewall day-to-day operation, i.e. gathering some stats, etc. to an inside machine. Firewall is composed of FreeBeasts (I like that spelling of FreeBSD! :) no fancy black Cisco boxen for filtering routers. As inside machine won't trust any part of firewall, the server part of a connection should reside on the firewall hosts. Yes, I know -- spoofing _is_ the issue, but might be eliminated by filtering inside addressee on external router/filter, which has virtually no access from outside. I want to get rid of all ways to aquire a shell on firewall hosts as a whole (thus physically remove rshd, telnetd, any-other-extra-d, leaving only publically available services and on the bastion host _only_). I don't want to have Perl5 executable hanging around, though I'm not sure that WWW server on bastion host (or it's admin, better to say) can live without it. The alternatives for rsh(1) I'm aware of are as following: 1. ssh-1.2.whatever. By far the superior thingie; but seems to be an overkill for using on a single-room-coax, needs some kind of public-key-crypto-awareness. 2. netpipes-3.0 package by Robert Forsman (comp.sources.unix, vol.29) A very simple pair of tools, allowing using socket connections from the shell scripts. 3. Hand-written daemon. Yes, that's probably Ok, but I need to have a stable list of needed tasks for it, so some scripted simple-rapid-and-dirty prototypes are needed, anyway. When the list of needed things to do will be well established, I'd probably replace prototypes with real compiled tools. So, I'm seriously considering netpipes as a transport -- only a server part is on the firewall machine(s), bound to a preselected set of ports, with /bin/sh script attached to it. Where am I wrong? -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "You may delegate authority, but not responsibility." Frank's Management Rule #1. From owner-freebsd-security Sun Apr 28 09:58:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10613 for security-outgoing; Sun, 28 Apr 1996 09:58:33 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA10605 for ; Sun, 28 Apr 1996 09:58:31 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id JAA00331; Sun, 28 Apr 1996 09:55:10 -0700 (PDT) Message-Id: <199604281655.JAA00331@precipice.shockwave.com> To: "Andrew V. Stesin" cc: firewalls@greatcircle.com, security@freebsd.org Subject: Re: Q on using "netpipes" for firewall maintanance tasks In-reply-to: Your message of "Sun, 28 Apr 1996 17:10:12 +0300." <199604281410.RAA21377@office.elvisti.kiev.ua> Date: Sun, 28 Apr 1996 09:55:10 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: "Andrew V. Stesin" Subject: Q on using "netpipes" for firewall maintanance tasks Hello people, I'm now in a search for safer but convenient rsh(1) replacement for some tasks of firewall day-to-day operation, i.e. gathering some stats, etc. to an inside machine. Firewall is composed of FreeBeasts (I like that spelling of FreeBSD! :) no fancy black Cisco boxen for filtering routers. ... So, I'm seriously considering netpipes as a transport -- only a server part is on the firewall machine(s), bound to a preselected set of ports, with /bin/sh script attached to it. Where am I wrong? Not buying the cisco box. From owner-freebsd-security Sun Apr 28 18:06:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09283 for security-outgoing; Sun, 28 Apr 1996 18:06:40 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA09274 for ; Sun, 28 Apr 1996 18:06:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id SAA19131 for freebsd-security@freebsd.org; Sun, 28 Apr 1996 18:06:34 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199604290106.SAA19131@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: freebsd-security@freebsd.org Subject: CERT Advisory CA-96.09 - Vulnerability in rpc.statd Date: Sun, 28 Apr 96 18:06:34 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The following CERT Advisory documents a vulnerability in rstatd. It also states that BSD/OS is not vulnerable. Considering BSD/OS' and FreeBSD's common heritage, would FreeBSD also be not vulnerable? Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message [header deleted] Organization: CERT(sm) Coordination Center - +1 412-268-7090 ============================================================================= CERT(sm) Advisory CA-96.09 April 24, 1996 Topic: Vulnerability in rpc.statd - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a vulnerability in rpc.statd (rpc.statd is also known as statd on some systems). As of the date of this advisory, we have received no reports of this vulnerability being exploited. If exploited, this vulnerability can be used to remove any file that the root user can remove or to create any file that the root user can create. Section III and Appendix A contain information from vendors. Appendix B contains an example of a possible workaround. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-96.09.README We encourage you to check our README files regularly for updates on advisories that relate to your site. - ----------------------------------------------------------------------------- I. Description rpc.statd, also called statd, is the NFS file-locking status monitor. It interacts with rpc.lockd, also called lockd, to provide the crash and recovery functions for file locking across NFS. NFS is stateless, which means that NFS clients and servers can be rebooted without a loss of file integrity due to NFS. In contrast, NFS file locking is stateful. To achieve this stateful nature in a stateless environment, rpc.lockd must work with rpc.statd to add state to file locking. To understand what rpc.statd does, it is first necessary to understand what rpc.lockd does. rpc.lockd processes lock requests that are sent either locally by the kernel or remotely by another lock daemon. rpc.lockd forwards lock requests for remote NFS files to the NFS server's lock daemon using Remote Procedure Calls (RPC). rpc.lockd then requests monitoring service from the status monitor daemon, rpc.statd, running on the NFS server. Monitoring services are needed because file locks are maintained in the NFS server kernel. In the event of a system crash or reboot, all NFS locks would normally be lost. It is rpc.statd that adds stateful file locking. When an NFS server reboots, rpc.statd causes the previously held locks to be recovered by notifying the NFS client lock daemons to resubmit previously granted lock requests. If a lock daemon fails to secure a previously granted lock on the NFS server, it sends SIGLOST to the process that originally requested the file lock. The vulnerability in rpc.statd is its lack of validation of the information it receives from what is presumed to be the remote rpc.lockd. Because rpc.statd normally runs as root and because it does not validate this information, rpc.statd can be made to remove or create any file that the root user can remove or create on the NFS server. II. Impact Any file that root could remove can be removed by rpc.statd. Any file that root could create can be created by rpc.statd, albeit with mode 200. III. Solution The general solution to this problem is to replace the rpc.statd daemon with one that validates the information sent to it by the remote rpc.lockd. We recommend that you install a patch from your vendor if possible. If a patch is not available for your system, we recommend contacting your vendor and requesting that a patch be developed as soon as possible. In the meantime, consider whether the information in Appendix B is applicable to your site. Vendor Information ------------------ Below is a summary list of the vendors who have reported to us as of the date of this advisory. Patch information and other details are in Appendix A of this advisory and reproduced in the CA-96.09.README file. We will update the README file as we receive more information. If your vendor's name is not on this list, please contact the vendor directly. Vendor Status ------ ------------ Apple Computer, Inc. vulnerable - A/UX version 3.1.1 and earlier; AIX 4.1.4 for the Apple Network Server Berkeley Software Design, Inc. not vulnerable - BSD/OS Cray Research, Inc. vulnerable - Unicos version 9.0 and higher Data General Corporation vulnerable - DG/UX R4.11 Digital Equipment Corporation vulnerable - UNIX (OSF/1) V3.0 through V3.2d; ULTRIX V4.3 through V4.5 Harris Computer Systems Corp. vulnerable - all versions of NightHawk CX/UX and PowerUX not vulnerable - all versions of NightHawk CX/SX and CyberGuard CX/SX Hewlett-Packard Company vulnerable - 9.X and 10.X IBM Corporation vulnerable - AIX 3.2 and 4.1 NEC Corporation some systems vulnerable NeXT Software, Inc. vulnerable - versions before 4.0; will be fixed in 4.0 The Santa Cruz Operation, Inc. not vulnerable - SCO UnixWare 2.x.; SCO OpenServer 3.0, 5; SCO Open Desktop 2.x, 3.x; SCO NFS 1.x.x. Silicon Graphics, Inc. vulnerable - all versions of IRIX except 6.2 not vulnerable - IRIX 6.2 Sony Corporation vulnerable - NEWS-OS 4.2.1, 6.0.3, 6.1, and 6.1.1 Sun Microsystems, Inc. believed to be vulnerable - SunOS 4.x and Solaris 2.x - --------------------------------------------------------------------------- The CERT Coordination Center thanks Andrew Gross of the San Diego Supercomputer Center for reporting this problem and Wolfgang Ley of DFN-CERT for his support in responding to this problem. - --------------------------------------------------------------------------- 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 (FIRST). We strongly urge you to encrypt any sensitive information you send by email. The CERT Coordination Center can support a shared DES key and PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key CERT 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 CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP 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 CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. ......................................................................... Appendix A: Vendor Information Current as of April 24, 1996 See CA-96.09.README for updated information. Below is information we have received from vendors concerning the vulnerability described in this advisory. If you do not see your vendor's name, please contact the vendor directly for information. Apple Computer, Inc. ==================== A/UX - ---- An upgrade to A/UX version 3.1 (and 3.1.1) for this vulnerability is available. The upgrade replaces the rpc.statd binary with a new, improved version. It is available via anonymous FTP from ftp.support.apple.com: pub/apple_sw_updates/US/Unix/A_UX/supported/3.x/rpc.statd/rpc.statd.Z Uncompress(1) this file and replace the existing version in /etc. Modify the entry for rpc.statd in /etc/inittab to "respawn" instead of "wait". Kill the running rpc.statd and restart. Earlier versions of A/UX are not supported by this patch. Users of previous versions are encouraged to update their system or disable rpc.statd. AIX for the Apple Network Server - ------------------------------- An upgrade to AIX version 4.1.4 for the Network Server which resolves this vulnerability is available. The PTF replaces the rpc.statd binary and related programs with new, improved versions. To determine if you already have APAR IX55931 on your system, run the following command: instfix -ik IX55931 Or run the following command: lslpp -h bos.net.nfs.client Your version of bos.net.nfs.client should be 4.1.4.7 or later. The PTF for this APAR is available via anonymous FTP from ftp.support.apple.com: pub/apple_sw_updates/US/Unix/AIX/supported/4.1/bos.net.nfs.client.bff Place this file in /usr/sys/inst.images or another directory of your choice. To install the PTF, start smit using the following fast path: # smit install_selectable Select the menu item "Install Fileset Updates by Fix" and provide the name of the directory in which the PTF was placed. Enter OK and in the next dialog, enter the APAR number, IX55931, in the "FIXES" item. For information about the other options in this dialog, see the manual page for installp(1). Enter OK, exit smit and restart the system. Customers should contact their reseller for any additional information. Berkeley Software Design, Inc. ============================= BSD/OS is not vulnerable. Cray Research, Inc. =================== This problem has been tracked with SPR 99983 and reported with Field notice 2107. Since statd is only available on 9.0 systems fixes have been provided for UNICOS 9.0 and higher. Data General Corporation ======================== Data General has fixed this vulnerability in DG/UX R4.11 Maintenance Update 2 (R4.11MU02). Digital Equipment Corporation ============================= At the time of writing this document, patches (binary kits) for Digital's ULTRIX operating system are being developed - V4.3 (both VAX and RISC) thru V4.5. Similar patches (binary kits) for Digital UNIX (OSF/1) versions 3.0 thru 3.2d are being tested. Digital will provide notice of the completion of the kits through AES services (DIA, DSNlink FLASH) and be available from your normal Digital Support channel. Digital's Software Security Response Team 16.APR.1996 Harris Computer Systems Corporation =================================== All versions of NightHawk CX/SX and CyberGuard CX/SX are not vulnerable. All versions of NightHawk CX/UX and PowerUX are vulnerable. Users are advised, until patches are available, to use the workaround in the advisory. Hewlett-Packard Company ======================= Vulnerable - 9.X & 10.X (i.e., all that are currently supported) Patches are in process; watch for an HP security bulletin. IBM Corporation =============== See the appropriate release below to determine your action. AIX 3.2 ------- Apply the following fix to your system: APAR - IX56056 (PTF - U441411) To determine if you have this PTF on your system, run the following command: lslpp -lB U441411 AIX 4.1 ------- Apply the following fix to your system: APAR - IX55931 To determine if you have this APAR on your system, run the following command: instfix -ik IX55931 Or run the following command: lslpp -h bos.net.nfs.client Your version of bos.net.nfs.client should be 4.1.4.7 or later. To Order -------- APARs may be ordered using FixDist or from the IBM Support Center. For more information on FixDist, reference URL: http://aix.boulder.ibm.com/pbin-usa/fixdist.pl/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". NEC Corporation =============== Some systems are vulnerable. We are developing the patches and plan to put them on our anonymous FTP server. You can contact us with the following e-mail address if you need. E-mail: UX48-security-support@nec.co.jp FTP server: ftp://ftp.meshnet.or.jp NeXT Software, Inc. =================== This vulnerability will be fixed in release 4.0 of OpenStep for Mach, scheduled for 2Q96. The Santa Cruz Operation, Inc. ============================== These are not vulnerable: SCO UnixWare 2.x. SCO OpenServer 3.0, 5 SCO Open Desktop 2.x, 3.x SCO NFS 1.x.x. Silicon Graphics, Inc. ====================== All versions of IRIX earlier than 6.2 are vulnerable. IRIX 6.2 is not vulnerable. Sony Corporation ================ NEWS-OS 4.2.1 vulnerable; Patch 0124 [rpc.statd] is available. NEWS-OS 6.0.3 vulnerable; Patch SONYP6063 [lockd/statd 2] is available. NEWS-OS 6.1 vulnerable; Patch SONYP6176 [lockd/statd] is available. NEWS-OS 6.1.1 vulnerable; Patch SONYP6207 [lockd/statd] is available. Patches are available via anonymous FTP in the /pub/patch/news-os/un-official directory on ftp1.sony.co.jp [202.238.80.18]: 4.2.1a+/0124.doc describes about patch 0124 [rpc.statd] 4.2.1a+/0124_C.pch patch for NEWS-OS 4.2.1C/a+C 4.2.1a+/0124_R.pch patch for NEWS-OS 4.2.1R/RN/RD/aRD/aRS/a+R 6.0.3/SONYP6063.doc describes about patch SONYP6063 [lockd/statd 2] 6.0.3/SONYP6063.pch patch for NEWS-OS 6.0.3 6.1/SONYP6176.doc describes about patch SONYP6176 [lockd/statd] 6.1/SONYP6176.pch patch for NEWS-OS 6.1 6.1.1/SONYP6207.doc describes about patch SONYP6207 [lockd/statd] 6.1.1/SONYP6207.pch patch for NEWS-OS 6.1.1 If you need further information, contact your dealer. Sun Microsystems, Inc. ====================== SunOS 4.x and Solaris 2.x are believed to be vulnerable. When further information is available, it will be placed in CA-96.09.README. ......................................................................... Appendix B: Example Workaround Scenario The information given below was provided to the CERT/CC by Wolfgang Ley of DFN-CERT. It is reproduced here as an example of how to run the statd daemon as a user other than root on a Solaris system. This workaround may not be directly applicable on other vendor's systems, but an analogous solution may be possible. Please contact your vendor for assistance. The statd daemon under Solaris 2.4 and 2.5 starts without problems if the following steps are taken. 1) Go into single user mode (ensure rpcbind and statd are not running) 2) Create a new user, e.g., "statd" with a separate uid/gid 3) Chown statd /var/statmon/* /var/statmon/*/* 4) Chgrp statd /var/statmon/* /var/statmon/*/* 5) Edit /etc/init.d/nfs.client startup script and change the start of the statd from: /usr/lib/nfs/statd > /dev/console 2>&1 to: /usr/bin/su - statd -c "/usr/lib/nfs/statd" > /dev/console 2>&1 6) Reboot the system ------- End of Forwarded Message From owner-freebsd-security Sun Apr 28 19:32:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA13926 for security-outgoing; Sun, 28 Apr 1996 19:32:15 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA13913 for ; Sun, 28 Apr 1996 19:32:08 -0700 (PDT) Message-Id: <199604290232.TAA13913@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA212404949; Mon, 29 Apr 1996 12:29:09 +1000 From: Darren Reed Subject: Re: Q on using "netpipes" for firewall maintanance tasks To: pst@shockwave.com (Paul Traina) Date: Mon, 29 Apr 1996 12:29:09 +1000 (EST) Cc: stesin@elvisti.kiev.ua, firewalls@GreatCircle.COM, security@freebsd.org In-Reply-To: <199604281655.JAA00331@precipice.shockwave.com> from "Paul Traina" at Apr 28, 96 09:55:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Paul Traina, sie said: > > > From: "Andrew V. Stesin" > Subject: Q on using "netpipes" for firewall maintanance tasks > Hello people, > > I'm now in a search for safer but convenient rsh(1) replacement for some > tasks of firewall day-to-day operation, i.e. gathering some stats, etc. > to an inside machine. Firewall is composed of FreeBeasts (I like > that spelling of FreeBSD! :) no fancy black Cisco boxen for filtering > routers. > > ... > > So, I'm seriously considering netpipes as a transport -- only a server > part is on the firewall machine(s), bound to a preselected set > of ports, with /bin/sh script attached to it. > > Where am I wrong? > > Not buying the cisco box. Is this just a blatant marketting plug or is there a reason behind this ? From owner-freebsd-security Sun Apr 28 23:17:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA24622 for security-outgoing; Sun, 28 Apr 1996 23:17:48 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA24617 for ; Sun, 28 Apr 1996 23:17:46 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id XAA01257; Sun, 28 Apr 1996 23:13:54 -0700 (PDT) Message-Id: <199604290613.XAA01257@precipice.shockwave.com> To: Darren Reed cc: stesin@elvisti.kiev.ua, firewalls@GreatCircle.COM, security@freebsd.org Subject: Re: Q on using "netpipes" for firewall maintanance tasks In-reply-to: Your message of "Mon, 29 Apr 1996 12:29:09 +1000." <199604290232.TAA13913@freefall.freebsd.org> Date: Sun, 28 Apr 1996 23:13:54 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: Darren Reed Subject: Re: Q on using "netpipes" for firewall maintanance tasks > Where am I wrong? > Not buying the cisco box. Is this just a blatant marketting plug or is there a reason behind this ? Who, me? I'm just a stockholder. :-) From owner-freebsd-security Mon Apr 29 01:13:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA00507 for security-outgoing; Mon, 29 Apr 1996 01:13:41 -0700 (PDT) Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.125.68.131]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA00454 for ; Mon, 29 Apr 1996 01:11:09 -0700 (PDT) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by burka.carrier.kiev.ua (Sendmail 8.who.cares/5) with ESMTP id KAA02307; Mon, 29 Apr 1996 10:58:06 +0300 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id KAA13914; Mon, 29 Apr 1996 10:44:13 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by acc0.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id KAA14482; Mon, 29 Apr 1996 10:35:58 +0300 (EET DST) Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id KAA24543; Mon, 29 Apr 1996 10:35:56 +0300 From: "Andrew V. Stesin" Message-Id: <199604290735.KAA24543@office.elvisti.kiev.ua> Subject: Re: Q on using "netpipes" for firewall maintanance tasks To: avalon@coombs.anu.edu.au (Darren Reed) Date: Mon, 29 Apr 1996 10:35:55 +0300 (EET DST) Cc: firewalls@greatcircle.com, security@freebsd.org In-Reply-To: <199604290234.TAA01223@miles.greatcircle.com> from "Darren Reed" at Apr 29, 96 12:29:09 pm X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello once more, # In some mail from Paul Traina, sie said: [... I asked about a way of monitoring firewall boxen with kinda of "shell RPC" ;-) ...] # > Where am I wrong? # > # > Not buying the cisco box. # # Is this just a blatant marketting plug or is there a reason behind this ? # As I already mentioned in a private e-mail to Mr.Traina, Cisco's are out of game not because I don't respect them by any reason, but because of cost and support issues just in my local area. Of course, I'm really interesting in the technical details about "what Cisco is able to do which FreeBSD cannot", I'm familiar with FreeBSD but not with Cisco's "black boxes". (Isn't this aspect important from security point of view, too?) -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "You may delegate authority, but not responsibility." Frank's Management Rule #1. From owner-freebsd-security Mon Apr 29 12:48:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06881 for security-outgoing; Mon, 29 Apr 1996 12:48:05 -0700 (PDT) Received: from mistery.mcafee.com (jimd@mistery.mcafee.com [192.187.128.69]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06839 for ; Mon, 29 Apr 1996 12:48:02 -0700 (PDT) Received: (from jimd@localhost) by mistery.mcafee.com (8.6.11/8.6.9) id MAA01121; Mon, 29 Apr 1996 12:45:46 -0700 From: Jim Dennis Message-Id: <199604291945.MAA01121@mistery.mcafee.com> Subject: Re: Q on using "netpipes" for firewall maintanance tasks To: pst@shockwave.com (Paul Traina) Date: Mon, 29 Apr 1996 12:45:45 -0700 (PDT) Cc: stesin@elvisti.kiev.ua, firewalls@greatcircle.com, security@freebsd.org In-Reply-To: <199604281655.JAA00331@precipice.shockwave.com> from "Paul Traina" at Apr 28, 96 09:55:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > From: "Andrew V. Stesin" > Subject: Q on using "netpipes" for firewall maintanance tasks > Hello people, > > I'm now in a search for safer but convenient rsh(1) replacement for some > tasks of firewall day-to-day operation, i.e. gathering some stats, etc. > to an inside machine. Firewall is composed of FreeBeasts (I like > that spelling of FreeBSD! :) no fancy black Cisco boxen for filtering > routers. What's wrong with ssh? Can't it do authenticated, encrypted rsh and rlogin? Jim Dennis, System Administrator, McAfee Associates From owner-freebsd-security Mon Apr 29 15:59:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20924 for security-outgoing; Mon, 29 Apr 1996 15:59:10 -0700 (PDT) Received: from spiff.gnu.ai.mit.edu (spiff.gnu.ai.mit.edu [128.52.46.13]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20918 for ; Mon, 29 Apr 1996 15:59:05 -0700 (PDT) Received: by spiff.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id SAA07646 for freebsd-security@FreeBSD.org; Mon, 29 Apr 1996 18:58:48 -0401 From: Kristyn Fayette Message-Id: <199604292259.SAA07646@spiff.gnu.ai.mit.edu> Subject: FreeBSD & firewalls To: freebsd-security@FreeBSD.org Date: Mon, 29 Apr 1996 18:58:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm getting ready to set up a firewall and I was wondering if anyone can give me some suggestions. Currently, I've got a firewall running on an Indy. It's using the internet firewall toolkit. Now I'm about to replace that machine with a FreeBSD system. Should I keep that toolkit, or should I use the ipfw program that comes with 2.1? I know this is the kind of question everyone hates...is brand X better than brand Y, but I really don't have much reference right now and time is kinda short. -----Kris -- -=(*)=- Kristyn Fayette -=(*)=- kristyn@gnu.ai.mit.edu From owner-freebsd-security Mon Apr 29 16:31:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA22658 for security-outgoing; Mon, 29 Apr 1996 16:31:45 -0700 (PDT) Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA22649 for ; Mon, 29 Apr 1996 16:31:37 -0700 (PDT) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id AAA11207; Tue, 30 Apr 1996 00:30:39 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Tue, 30 Apr 96 0:28:44 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 29 Apr 96 23:28:42 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Mon, 29 Apr 96 23:28:42 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:21237-960429232842-6570] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Mon, 29 Apr 96 23:28:42 +0000 Content-Identifier: Re: CERT Advisor Message-Id: <"11363-960429232834-79C3*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org In-Reply-To: <"SunOS:5836-960429012804-059C*/DD.RFC-822=owner-security(a)FreeBSD.ORG/O=internet/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/"@MHS> Subject: Re: CERT Advisory CA-96.09 - Vulnerability in rpc.statd Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The following CERT Advisory documents a vulnerability in rstatd. It also > states that BSD/OS is not vulnerable. Considering BSD/OS' and FreeBSD's > common heritage, would FreeBSD also be not vulnerable? > Topic: Vulnerability in rpc.statd ^^^ Actually, this is rpc.statd not rpc.rstatd. None of the -release versions contain any sort of rpc.statd at all, so are obviously not vulnerable. The version of rpc.statd in -current was written by me, and I do not believe it suffers from this. I find the wording of the advisory to be somewhat confused, seeing as the rpc.statd protocol doesn't pass any filenames at all, but my understanding of the problem is: - Most (Sun-derived) implementations store the status for remote hosts in a bunch of very small files /var/somewhere/ - The protocol does not prescribe any particular relationship between the hostname supplied in text in the protocol and the IP address from which the request came, and in any event the initial request is proxied through the local rpc.lockd so the statd doesn't get to see the original packet [this is the bit where I find the advisory to be confused]. - If you come along claiming that your hostname is "../../etc/passwd" and the rpc.statd is fool enough to believe you, it will go and store your status in that file. My implementation does not use one file per host, so does not suffer from this - I have one large file containing the host names and their statuses which I mmap(). Arguably my way is less efficient for very large numbers of client hosts, though I am now quite glad I did it that way. BTW - I never see FreeBSD quoted as a 'vendor' on these things. Is this because CERT doesn't recognise FreeBSD as a vendor, or just because there is no effort available to liase with CERT? Andrew. [PS. I promise to get back to work on the rpc.lockd when I get some vacation time this summer...] From owner-freebsd-security Mon Apr 29 17:38:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA26679 for security-outgoing; Mon, 29 Apr 1996 17:38:06 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA26673 for ; Mon, 29 Apr 1996 17:38:02 -0700 (PDT) Message-Id: <199604300038.RAA26673@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA062524672; Tue, 30 Apr 1996 10:37:52 +1000 From: Darren Reed Subject: Re: FreeBSD & firewalls To: kristyn@gnu.ai.mit.edu (Kristyn Fayette) Date: Tue, 30 Apr 1996 10:37:52 +1000 (EST) Cc: freebsd-security@freebsd.org In-Reply-To: <199604292259.SAA07646@spiff.gnu.ai.mit.edu> from "Kristyn Fayette" at Apr 29, 96 06:58:42 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Kristyn Fayette, sie said: > > Hi, > > I'm getting ready to set up a firewall and I was wondering if anyone can > give me some suggestions. Currently, I've got a firewall running on an Indy. > It's using the internet firewall toolkit. Now I'm about to replace that > machine with a FreeBSD system. Should I keep that toolkit, or should I use > the ipfw program that comes with 2.1? > > I know this is the kind of question everyone hates...is brand X better > than brand Y, but I really don't have much reference right now and time > is kinda short. If you want to use the FreeBSD box as a drop-in replacement, use the FWTK as you should be able to just copy over the config. files. You won't have to spend time creating new ones, verifying them, etc. If you're serious about doing firewalling with FreeBSD and moving away from the Firewall Toolkit, checkout http://coombs.anu.edu.au/~avalon/ip-filter.html - but only if you want to move away from the tookit, which, if it is working, I wouldn't recommend so long as you can build it easily on FreeBSD (you shouldn't have much trouble with 2.1). darren From owner-freebsd-security Mon Apr 29 18:09:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA27946 for security-outgoing; Mon, 29 Apr 1996 18:09:48 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA27934 for ; Mon, 29 Apr 1996 18:09:38 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id KAA04487; Tue, 30 Apr 1996 10:37:21 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA15421; Tue, 30 Apr 96 10:39:12 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9604300109.AA15421@communica.com.au> Subject: Re: FreeBSD & firewalls To: kristyn@gnu.ai.mit.edu (Kristyn Fayette) Date: Tue, 30 Apr 1996 10:39:11 +0930 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199604292259.SAA07646@spiff.gnu.ai.mit.edu> from "Kristyn Fayette" at Apr 29, 96 06:58:42 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Kristyn Fayette wrote: > I'm getting ready to set up a firewall and I was wondering if anyone can > give me some suggestions. Currently, I've got a firewall running on an Indy. > It's using the internet firewall toolkit. Now I'm about to replace that > machine with a FreeBSD system. Should I keep that toolkit, or should I use > the ipfw program that comes with 2.1? Point 1: Stick with what you know. If you're using TIS now, keep using TIS. Point 2: Be aware that a single computer doesn't make a very good firewall! Simply plonking a UNIX box onto the network between you and your ISP is not going to deliver anywhere near what *I* would consider acceptable security (what you would consider acceptable may legitimately differ, though) Just my (professional) opinion... - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Mon Apr 29 23:51:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA12794 for security-outgoing; Mon, 29 Apr 1996 23:51:10 -0700 (PDT) Received: from rachael.franken.de (rachael.franken.de [193.175.24.38]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA12788 for ; Mon, 29 Apr 1996 23:51:06 -0700 (PDT) Received: from hub-wue.franken.de by rachael.franken.de with smtp (Smail3.1.29.1 #8) id m0uE9Gw-000oHrC; Tue, 30 Apr 96 08:50 MET DST Received: from wuff.franken.de by hub-wue.franken.de with smtp (Smail3.1.29.1 #16) id m0uE9H2-000FzpC; Tue, 30 Apr 96 08:51 MET DST Received: by wuff.franken.de (Smail3.1.29.1 #20) id m0uE9Gl-000OxGA; Tue, 30 Apr 96 08:50 MET DST Received: (from marc@localhost) by sniff.franken.de (8.7.5/8.7.3/uuB) id IAA00897; Tue, 30 Apr 1996 08:49:54 +0200 (MET DST) From: Marc Binderberger Message-Id: <199604300649.IAA00897@sniff.franken.de> Subject: Re: FreeBSD & firewalls To: kristyn@gnu.ai.mit.edu (Kristyn Fayette) Date: Tue, 30 Apr 1996 08:49:54 +0200 (MET DST) Cc: freebsd-security@freebsd.org In-Reply-To: <199604292259.SAA07646@spiff.gnu.ai.mit.edu> from "Kristyn Fayette" at Apr 29, 96 06:58:42 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello Kristyn! I don't know Indy's, so I'm not sure ... > Currently, I've got a firewall running on an Indy. > It's using the internet firewall toolkit. ... if you are talking about the TIS firewall toolkit or any vendor specific software. > machine with a FreeBSD system. Should I keep that toolkit, or should I use > the ipfw program that comes with 2.1? But if your are taking about the TIS package, you should use _both_. IPFW is a packet filter, the TIS package contains application level filters and proxies. Use the IPFW to stop source routed IP and all the stuff you can easily set into rules. Authentication schemes like S/key, X gateways with confirmation or anti-java(script) filters are the task of the TIS toolkits. Regards, Marc. -- Marc Binderberger 97076 Wuerzburg, Germany marc@sniff.franken.de Powered by FreeBSD ;-) From owner-freebsd-security Tue Apr 30 02:59:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA24820 for security-outgoing; Tue, 30 Apr 1996 02:59:54 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA24812 for ; Tue, 30 Apr 1996 02:59:50 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.12/1.53) id LAA13927; Tue, 30 Apr 1996 11:25:23 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199604300925.LAA13927@gvr.win.tue.nl> Subject: Re: ptrace vulnerability, was: Something fishy with our PT_ATTACH code! To: ghelmer@alpha.dsu.edu (Guy Helmer) Date: Tue, 30 Apr 1996 11:25:22 +0200 (MET DST) Cc: security@freebsd.org In-Reply-To: from "Guy Helmer" at Apr 26, 96 08:44:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guy Helmer wrote: > > That reminds me, did BSDI release any information/patches regarding the > ptrace vulnerabilitiy (CERT VB-96.04.bsdi)? I assume the 4.4BSD-derived > systems had the same ptrace code... > When I looked at the sources in FreeBSD and to the supplied patch by BSDI, it seemed the two are totally different pieces of code. -Guido From owner-freebsd-security Tue Apr 30 07:02:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA09015 for security-outgoing; Tue, 30 Apr 1996 07:02:42 -0700 (PDT) Received: from umbc7.umbc.edu (pauld@f-umbc7.umbc.edu [130.85.3.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA09009 for ; Tue, 30 Apr 1996 07:02:37 -0700 (PDT) Received: (from pauld@localhost) by umbc7.umbc.edu (8.6.12/Umbc) id KAA28198; Tue, 30 Apr 1996 10:02:16 -0400 Date: Tue, 30 Apr 1996 10:02:16 -0400 (EDT) From: Paul Danckaert To: Mark Newton cc: Kristyn Fayette , freebsd-security@freebsd.org Subject: Re: FreeBSD & firewalls In-Reply-To: <9604300109.AA15421@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Apr 1996, Mark Newton wrote: > > Point 2: Be aware that a single computer doesn't make a very good > firewall! Simply plonking a UNIX box onto the network between you and > your ISP is not going to deliver anywhere near what *I* would consider > acceptable security (what you would consider acceptable may legitimately > differ, though) I agree that simply dropping a box on the net, running ipfw or whatever on it, and calling yourself safe isn't completely true, but I'm curious what you would do to build a safer network? I would hope that your external router would do alot of blocks, before data ever makes it to your firewall box, but what about in some of the hybrid situations that FreeBSD works well in? For example, when people drop a T1 card into a box, a few ethernet cards, and make it their external router itself? Also, I'm just curious and haven't looked too much into it, but has anybody used BSD to firewall people within a site? For example, we are looking at putting dorms on ethernet, but we are going to block various protocols, ports, etc.. has anybody used a BSD solution to this sort of problem? Any recomendations on software? paul From owner-freebsd-security Tue Apr 30 08:39:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA15766 for security-outgoing; Tue, 30 Apr 1996 08:39:28 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA15759 for ; Tue, 30 Apr 1996 08:39:24 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA00587; Tue, 30 Apr 1996 08:38:50 -0700 (PDT) Message-Id: <199604301538.IAA00587@precipice.shockwave.com> X-Mailer: exmh version 1.6.6 3/24/96 To: cschuber@orca.gov.bc.ca Cc: freebsd-security@FreeBSD.ORG Subject: Re: CERT Advisory CA-96.09 - Vulnerability in rpc.statd In-Reply-To: Your message of "Sun, 28 Apr 1996 18:06:34 PDT." <199604290106.SAA19131@passer.osg.gov.bc.ca> Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=73D288A5 Content-Transfer-Encoding: 7bit Date: Tue, 30 Apr 1996 08:38:49 -0700 From: Paul Traina Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Our statd is not vulnerable. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMYY0B1UuHi5z0oilAQFvlQP/dQe6/ejidbhEd7K/Mo4c3WM0P9GVOUW4 OVB/wbCg37YmkI6q0ohR3qGat2ILv5CvoOQAALA4OXp/hKZ/TZopesTdLlpdsMMm o+m/ZsAujE2IaWKyEFni5F0u6iofPzZBboqYtSCmQG/lFeNqSvBDPcfcMPLLIZNH ya/GcDOh3ro= =E+Sm -----END PGP SIGNATURE----- From owner-freebsd-security Tue Apr 30 08:43:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA16048 for security-outgoing; Tue, 30 Apr 1996 08:43:28 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA16043 for ; Tue, 30 Apr 1996 08:43:23 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA00619; Tue, 30 Apr 1996 08:40:18 -0700 (PDT) Message-Id: <199604301540.IAA00619@precipice.shockwave.com> X-Mailer: exmh version 1.6.6 3/24/96 To: Andrew.Gordon@net-tel.co.uk cc: cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org Subject: Re: CERT Advisory CA-96.09 - Vulnerability in rpc.statd In-reply-to: Your message of "Mon, 29 Apr 1996 23:28:42 -0000." <"11363-960429232834-79C3*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Apr 1996 08:40:17 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > BTW - I never see FreeBSD quoted as a 'vendor' on these things. Is this because CERT doesn't recognise FreeBSD as a vendor, or just because there is no effort available to liase with CERT? I'm working on that right now. We should have a formal relationship soon. From owner-freebsd-security Tue Apr 30 17:51:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA27347 for security-outgoing; Tue, 30 Apr 1996 17:51:19 -0700 (PDT) Received: from arnie.systems.sa.gov.au (arnie.systems.sa.gov.au [143.216.242.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA27335 for ; Tue, 30 Apr 1996 17:51:06 -0700 (PDT) Received: from state.systems.sa.gov.au by arnie.systems.sa.gov.au (PMDF V4.3-7 #13538) id <01I46RTV0DTS007K44@arnie.systems.sa.gov.au>; Wed, 1 May 1996 10:14:18 +1030 Received: from dogbert.systems.sa.gov.au (dogbert.systems.sa.gov.au) by state.systems.sa.gov.au (PMDF V5.0-4 #13538) id <01I46RTIKH7K0072D8@state.systems.sa.gov.au>; Wed, 01 May 1996 10:14:00 +0930 Received: from jolt.systems.sa.gov.au (jolt.systems.sa.gov.au [143.216.237.8]) by dogbert.systems.sa.gov.au (8.6.12/8.6.12) with SMTP id KAA14203; Wed, 01 May 1996 10:17:04 +0930 Date: Wed, 01 May 1996 10:16:55 +0930 From: Garth Kidd Subject: Re: FreeBSD & firewalls In-reply-to: Paul Danckaert <"Re: FreeBSD & firewalls"@state.systems.sa.gov.au> (Apr 30, 10:02) To: Paul Danckaert , Mark Newton Cc: Kristyn Fayette , freebsd-security@FreeBSD.org Message-id: <960501101804.ZM2871@jolt.systems.sa.gov.au> MIME-version: 1.0 X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Apr 30, 10:02, Paul Danckaert wrote: > Also, I'm just curious and haven't looked too much into it, but has > anybody used BSD to firewall people within a site? For example, we are > looking at putting dorms on ethernet, but we are going to block various > protocols, ports, etc.. Great idea. Those dorms are a real security threat, and I completely understand wanting to firewall yourself off from them :). [I'm at least a measure serious, actually; what are you trying to protect?] -- garth@dogbert.systems.sa.gov.au | Garth Kidd +61-8-207-7740 (voice) | Network Services Branch +61-8-207-7860 (fax) | EDS | Adelaide, AUSTRALIA From owner-freebsd-security Tue Apr 30 17:51:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA27363 for security-outgoing; Tue, 30 Apr 1996 17:51:30 -0700 (PDT) Received: from arnie.systems.sa.gov.au (arnie.systems.sa.gov.au [143.216.242.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA27356 for ; Tue, 30 Apr 1996 17:51:23 -0700 (PDT) Received: from state.systems.sa.gov.au by arnie.systems.sa.gov.au (PMDF V4.3-7 #13538) id <01I46RTRATRK007O5T@arnie.systems.sa.gov.au>; Wed, 1 May 1996 10:14:14 +1030 Received: from dogbert.systems.sa.gov.au (dogbert.systems.sa.gov.au) by state.systems.sa.gov.au (PMDF V5.0-4 #13538) id <01I46RTDREI80074CB@state.systems.sa.gov.au>; Wed, 01 May 1996 10:13:54 +0930 Received: from jolt.systems.sa.gov.au (jolt.systems.sa.gov.au [143.216.237.8]) by dogbert.systems.sa.gov.au (8.6.12/8.6.12) with SMTP id KAA14197; Wed, 01 May 1996 10:16:51 +0930 Date: Wed, 01 May 1996 10:10:38 +0930 From: Garth Kidd Subject: Re: FreeBSD & firewalls In-reply-to: newton@communica.com.au (Mark Newton) "Re: FreeBSD & firewalls" (Apr 30, 10:39) To: newton@communica.com.au (Mark Newton), kristyn@gnu.ai.mit.edu (Kristyn Fayette) Cc: freebsd-security@FreeBSD.ORG Message-id: <960501101757.ZM2871@jolt.systems.sa.gov.au> MIME-version: 1.0 X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <9604300109.AA15421@communica.com.au> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Apr 30, 10:39, Mark Newton wrote: > Point 2: Be aware that a single computer doesn't make a very good > firewall! Simply plonking a UNIX box onto the network between you and > your ISP is not going to deliver anywhere near what *I* would consider > acceptable security (what you would consider acceptable may > legitimately differ, though) > > Just my (professional) opinion... I suspect it's reaching the point where the resources necessary to maintain comprehensive network security are beyond the reach of many sites. Defense in depth with DMZ-style twin router, bastion host and inner peer configurations with dedicated logging hosts and personnel available 24/365 to handle detected intrusion attempts is _expensive_. [*] Anybody with a permament connection to the Internet should *expect* to have their firewall breached, and should plan accordingly. Particularly, even though you can't expect to prevent all intrusion attempts, you need to know when one is occurring or, worse, has succeeded, you need someone to clean up the damage and try to plug whatever hole was exploited, and you need regular backups that are stored for quite a while in case someone sneaks in and you don't notice it for a month. Mark, I expect I'm preaching to the converted in your case :) Prediction: some major ISPs will begin installing firewalls to protect their customers. The cost of maintaining a comprehensive firewall may well be bearable if spread amongst a few hundred customers. Perhaps firewalling will be an optional extra, suitably priced, so those customers who _insist_ on having "talk" or that don't believe their site will be targeted can be left out in the cold on their demand. Some US-based single-box firewall vendors offer remote monitoring services. Just plug in a modem and leave a connection open to your vendor, and they'll (allegedly) keep an eye on things for you. I'm not convinced, but it's certainly better than the same box with nobody watching. Something I'd like to see, though, is some serious discussion of the one-box problem for those that are home-brewing their firewall boxen. What should they do to ensure that they can at least *detect* a successful intrusion? *: Relying on a single host to protect your network is one extreme [**]. This configuration is, perhaps, the other. **: I lied. Connecting all of your systems to the Internet and hoping that nobody will find your site interesting enough to hack is the extreme. -- garth@dogbert.systems.sa.gov.au | Garth Kidd +61-8-207-7740 (voice) | Network Services Branch +61-8-207-7860 (fax) | EDS | Adelaide, AUSTRALIA From owner-freebsd-security Wed May 1 04:40:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA04082 for security-outgoing; Wed, 1 May 1996 04:40:11 -0700 (PDT) Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA04077 for ; Wed, 1 May 1996 04:40:05 -0700 (PDT) Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id HAA05720; Wed, 1 May 1996 07:38:58 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id HAA08293; Wed, 1 May 1996 07:34:46 -0400 Date: Wed, 1 May 1996 07:34:46 -0400 From: Gene Stark Message-Id: <199605011134.HAA08293@starkhome.cs.sunysb.edu> To: Paul Danckaert Cc: security@freebsd.org In-reply-to: Paul Danckaert's message of Tue, 30 Apr 1996 10:02:16 -0400 (EDT) Subject: Re: FreeBSD & firewalls References: <4m5u6d$4r3@starkhome.cs.sunysb.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Also, I'm just curious and haven't looked too much into it, but has >anybody used BSD to firewall people within a site? For example, we are >looking at putting dorms on ethernet, but we are going to block various >protocols, ports, etc.. has anybody used a BSD solution to this sort of >problem? Any recomendations on software? Yes, I am using ipfw primarily to prevent egress from a student lab. The purpose is to keep people from occupying seats in the lab while they play MUDs or IRC or use X to outside, and to keep them from setting up lots of quasi-commercial servers operating on machines within the lab. The ipfw code works more or less OK for this, but I found it a bit difficult to create the filters I wanted. Mostly, what I am doing is blocking TCP between endpoints inside and outside the lab, both ports of which are >= 1024. The main disadvantage of this seems to be that "passive FTP", or whatever it is that happens sometimes when you follow an ftp: link from an HTTP server and get a high numbered port, is blocked. - Gene Stark From owner-freebsd-security Wed May 1 09:59:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA00413 for security-outgoing; Wed, 1 May 1996 09:59:38 -0700 (PDT) Received: from umbc7.umbc.edu (pauld@f-umbc7.umbc.edu [130.85.3.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA00408 for ; Wed, 1 May 1996 09:59:30 -0700 (PDT) Received: (from pauld@localhost) by umbc7.umbc.edu (8.6.12/Umbc) id MAA25256; Wed, 1 May 1996 12:58:24 -0400 Date: Wed, 1 May 1996 12:58:23 -0400 (EDT) From: Paul Danckaert To: Garth Kidd cc: Mark Newton , Kristyn Fayette , freebsd-security@FreeBSD.org Subject: Re: FreeBSD & firewalls In-Reply-To: <960501101804.ZM2871@jolt.systems.sa.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 1 May 1996, Garth Kidd wrote: > On Apr 30, 10:02, Paul Danckaert wrote: > > > Also, I'm just curious and haven't looked too much into it, but has > > anybody used BSD to firewall people within a site? For example, we are > > looking at putting dorms on ethernet, but we are going to block various > > protocols, ports, etc.. > > Great idea. Those dorms are a real security threat, and I completely > understand wanting to firewall yourself off from them :). > > [I'm at least a measure serious, actually; what are you trying to protect?] Well, its really a minimal protection against IP spoofing, low level attacks, and for "policy enforcement". (Ie: We don't want to become an ISP, so we restrict logins from modem pools, etc..) I don't think we will have too many problems.. for example, I don't know how many people in our dorms would do low level NFS guess attacks, or anything like that.. but I would rather have something in place when we wire them up and not use it much, than having to put something in a year after.. paul From owner-freebsd-security Wed May 1 10:09:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA01131 for security-outgoing; Wed, 1 May 1996 10:09:21 -0700 (PDT) Received: from groovy.dreaming.org (groovy.dreaming.org [204.92.5.69]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA01125 for ; Wed, 1 May 1996 10:09:16 -0700 (PDT) Received: (from batsy@localhost) by groovy.dreaming.org (8.6.12/8.6.12) id NAA10934; Wed, 1 May 1996 13:25:58 -0400 Date: Wed, 1 May 1996 13:25:58 -0400 (EDT) From: jamie X-Sender: batsy@groovy.dreaming.org To: freebsd-security@freebsd.org Subject: docs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm sure that there is a digest version of this list somewhere but I was wondering if anyone has compiled an FAQ or a doc based upon the issues on this list? I have a few questions but before I ask them I was wondering if there was a doc that might have the answers on it as not to crowd the list. If not, should we start one?:) Just curious. jamie Jamie Reid batsy@groovy.dreaming.org www.groovy.dreaming.org From owner-freebsd-security Sat May 4 12:05:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20664 for security-outgoing; Sat, 4 May 1996 12:05:58 -0700 (PDT) Received: from mail.vividnet.com (mail.vividnet.com [206.149.144.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA20658 for ; Sat, 4 May 1996 12:05:53 -0700 (PDT) Received: from taurus.vividnet.com (postmaster@mail.vividnet.com) by mail.vividnet.com (8.7.4/8.7.5) with ESMTP id MAA29852 for ; Sat, 4 May 1996 12:03:41 -0700 (PDT) Received: (postmaster@taurus.vividnet.com) by taurus.vividnet.com (8.7.4/8.6.9) id MAA09664; Sat, 4 May 1996 12:07:21 -0700 (PDT) Date: Sat, 4 May 1996 12:07:21 -0700 (PDT) From: Brian Wang To: freebsd-security@freebsd.org Subject: Weird system security output Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After searching the mail archives, I found the following posted question without replies. I'd love some replies though. > Subject: unaccounted-for mtime and ctime changes on SUID root programs > To: questions@FreeBSD.org (FreeBSD questions) > Date: Thu, 1 Feb 1996 10:36:26 -0600 (CST) > X-Mailer: ELM [version 2.4 PL25] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-questions@FreeBSD.org > Precedence: bulk > > A few times with FreeBSD 2.0.5 and now twice with FreeBSD 2.1(CD), > the nightly security check has revealed SUID root programs whose > modification times have changed. I have immediately put in the > backup tapes, pulled down the original files, and compared them. > Every time, they have been identical (which is something of a relief > to know that worms or trojan horses are not being left around), but > I have to wonder how this is happening, and whether it may be an > indication of something sinister but more subtle going on (like someone > changing the programs, doing their mischief, and then changing them > back). Just last night, I'm having the same problem described above again (It occured couple of times before). Somehow, the date stamp gets altered for no reason...a compromised system? Again, checking the binary file from the backup/cdrom yielded nothing. The following is a nightly security check output from one of our server. Is there a rational explanation for this? Thanks in advance for any help/answer! Date: Sat, 4 May 1996 02:00:03 -0700 (PDT) From: System Administrator Subject: aquarius security check output checking setuid files and devices: aquarius setuid/device diffs: 1c1 < -r-xr-sr-x 1 bin operator 65536 Nov 16 01:43:41 1995 /bin/df --- > -r-xr-sr-x 1 bin operator 65536 May 3 02:22:47 1996 /bin/df Sincerely, Brian Wang From owner-freebsd-security Sat May 4 13:53:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26077 for security-outgoing; Sat, 4 May 1996 13:53:29 -0700 (PDT) Received: from falcon.tioga.com (root@falcon.tioga.com [205.146.65.5]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA26062 for ; Sat, 4 May 1996 13:53:24 -0700 (PDT) Received: (from tbalfe@localhost) by falcon.tioga.com (8.7.5/8.6.12) id QAA10801; Sat, 4 May 1996 16:53:49 GMT Date: Sat, 4 May 1996 16:53:49 +0000 () From: Thomas J Balfe To: security@freebsd.org Subject: sendmail Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have recently compiled sendmail from cert.org. What I want to know, does sendmail have to be mode 4555 to function correctly, or will be function correctly as mode 555? Or even 4111? ======================================================================== Thomas J Balfe tbalfe@tioga.com President http://www.tioga.com/ Tioga Communications, Inc 814-867-4770 ======================================================================== From owner-freebsd-security Sat May 4 15:23:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06257 for security-outgoing; Sat, 4 May 1996 15:23:36 -0700 (PDT) Received: from groovy.dreaming.org (groovy.dreaming.org [204.92.5.69]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06252 for ; Sat, 4 May 1996 15:23:30 -0700 (PDT) Received: (from batsy@localhost) by groovy.dreaming.org (8.6.12/8.6.12) id SAA07235; Sat, 4 May 1996 18:31:10 -0400 Date: Sat, 4 May 1996 18:31:10 -0400 (EDT) From: jamie X-Sender: batsy@groovy.dreaming.org To: Brian Wang cc: freebsd-security@FreeBSD.ORG Subject: Re: Weird system security output In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Just last night, I'm having the same problem described above again > (It occured couple of times before). Somehow, the date stamp gets altered > for no reason...a compromised system? Again, checking the binary file > from the backup/cdrom yielded nothing. The following is a nightly > security check output from one of our server. Is there a rational > explanation for this? Thanks in advance for any help/answer! I have had this happen and have rationalized it, but I'm not sure if it is a cause. I always thought that it was because of the sup process adding new files and updating current ones. If I'm dead wrong please correct me. I am the walrus. batsy@groovy.dreaming.org www.groovy.dreaming.org From owner-freebsd-security Sat May 4 15:29:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06446 for security-outgoing; Sat, 4 May 1996 15:29:09 -0700 (PDT) Received: from mail.vividnet.com (mail.vividnet.com [206.149.144.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA06441 for ; Sat, 4 May 1996 15:29:04 -0700 (PDT) Received: from taurus.vividnet.com (postmaster@mail.vividnet.com) by mail.vividnet.com (8.7.4/8.7.5) with ESMTP id PAA00984; Sat, 4 May 1996 15:26:56 -0700 (PDT) Received: (postmaster@taurus.vividnet.com) by taurus.vividnet.com (8.7.4/8.6.9) id PAA10008; Sat, 4 May 1996 15:30:36 -0700 (PDT) Date: Sat, 4 May 1996 15:30:36 -0700 (PDT) From: Brian Wang To: jamie cc: freebsd-security@FreeBSD.ORG Subject: Re: Weird system security output In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 4 May 1996, jamie wrote: > > Just last night, I'm having the same problem described above again > > (It occured couple of times before). Somehow, the date stamp gets altered > > for no reason...a compromised system? Again, checking the binary file > > from the backup/cdrom yielded nothing. The following is a nightly > > security check output from one of our server. Is there a rational > > explanation for this? Thanks in advance for any help/answer! > > > I have had this happen and have rationalized it, but I'm not sure if it > is a cause. I always thought that it was because of the sup process > adding new files and updating current ones. If I'm dead wrong please > correct me. We never sup...not even once yet. Our servers are running off stock FreeBSD2.1 release. From owner-freebsd-security Sat May 4 15:50:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07504 for security-outgoing; Sat, 4 May 1996 15:50:10 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA07497 for ; Sat, 4 May 1996 15:50:07 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id RAA00682; Sat, 4 May 1996 17:49:32 -0500 (EST) From: "John S. Dyson" Message-Id: <199605042249.RAA00682@dyson.iquest.net> Subject: Re: Weird system security output To: batsy@groovy.dreaming.org (jamie) Date: Sat, 4 May 1996 17:49:32 -0500 (EST) Cc: brian@mail.vividnet.com, freebsd-security@FreeBSD.ORG In-Reply-To: from "jamie" at May 4, 96 06:31:10 pm Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I have had this happen and have rationalized it, but I'm not sure if it > is a cause. I always thought that it was because of the sup process > adding new files and updating current ones. If I'm dead wrong please > correct me. > There IS a bug in -stable (might have been fixed recently) that modified dates on executables can get modified during paging. We just found a very subtile bug in pmap.c (it might be in the asm statements or in the register allocation associated with them), that appears to have been fixed when we rewrote the code. The bug that appears to have been fixed also could have been manifested by changed modify dates. This is a very very tough one. John