From owner-freebsd-security Wed Apr 17 10:20:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA20468 for security-outgoing; Wed, 17 Apr 1996 10:20:18 -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 SMTP id KAA20459 for ; Wed, 17 Apr 1996 10:20:12 -0700 (PDT) Received: (from tbalfe@localhost) by falcon.tioga.com (8.6.12/8.6.12) id NAA13990; Wed, 17 Apr 1996 13:20:05 GMT Date: Wed, 17 Apr 1996 13:20:05 +0000 () From: Thomas J Balfe To: freebsd-security@freebsd.org Subject: X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it safer to run xdmcp or rexecd? I want to have some of my machintoshes have access to a machine of mine for X. I am assuming that rsh is the wrong way to go about it. ============================================================================== Thomas J Balfe tbalfe@tioga.com President http://www.tioga.com/ Tioga Communications, Inc 814-867-4770 ============================================================================== From owner-freebsd-security Wed Apr 17 12:44:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA00897 for security-outgoing; Wed, 17 Apr 1996 12:44:27 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA00891 for ; Wed, 17 Apr 1996 12:44:25 -0700 (PDT) Received: (from scanner@localhost) by orion.webspan.net (8.6.12/8.6.12) id PAA03294; Wed, 17 Apr 1996 15:43:57 -0400 Date: Wed, 17 Apr 1996 15:43:57 -0400 (EDT) From: Scanner SOD To: Thomas J Balfe cc: freebsd-security@FreeBSD.org Subject: Re: X 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 Wed, 17 Apr 1996, Thomas J Balfe wrote: > Is it safer to run xdmcp or rexecd? I want to have some of my > machintoshes have access to a machine of mine for X. I am assuming that > rsh is the wrong way to go about it. Im assuming you want the macs to use the X programs on your X box on your macs. like xhost. If so just use SSH with X11 forwarding on. That will create a secure tunnel that all your X proggies will go thru. It is the safest way i know of to do it. ===================================| Webspan Inc., ISP Division. FreeBSD 2.1.0 is available now! | Phone: 908-367-8030 ext. 126 -----------------------------------| 500 West Kennedy Blvd., Lakewood, NJ-94945 Turning PCs into Workstations | E-Mail: scanner@webspan.net ===================================| SysAdmin / Network Engineer / Consultant From owner-freebsd-security Wed Apr 17 16:31:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA24261 for security-outgoing; Wed, 17 Apr 1996 16:31:20 -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 QAA24254 for ; Wed, 17 Apr 1996 16:31:16 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id IAA10788; Thu, 18 Apr 1996 08:53:52 +0930 From: Michael Smith Message-Id: <199604172323.IAA10788@genesis.atrad.adelaide.edu.au> Subject: Re: X To: tbalfe@tioga.com (Thomas J Balfe) Date: Thu, 18 Apr 1996 08:53:52 +0930 (CST) Cc: freebsd-security@FreeBSD.org In-Reply-To: from "Thomas J Balfe" at Apr 17, 96 01:20:05 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 Thomas J Balfe stands accused of saying: > > Is it safer to run xdmcp or rexecd? I want to have some of my > machintoshes have access to a machine of mine for X. I am assuming that > rsh is the wrong way to go about it. Correct. xdmcp is good. > Thomas J Balfe tbalfe@tioga.com -- ]] 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 Thu Apr 18 02:15:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA24659 for security-outgoing; Thu, 18 Apr 1996 02:15:55 -0700 (PDT) Received: from hawk.gnome.co.uk (gnome.intecc.co.uk [194.72.95.90]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA24653 for ; Thu, 18 Apr 1996 02:15:39 -0700 (PDT) Received: (from jacs@localhost) by hawk.gnome.co.uk (8.7.5/8.7.3) id KAA01885; Thu, 18 Apr 1996 10:14:56 +0100 (BST) Date: Thu, 18 Apr 1996 10:14:56 +0100 (BST) From: Chris Stenton Subject: Re: X To: Michael Smith Cc: freebsd-security@freebsd.org, tbalfe@tioga.com Message-Id: In-Reply-To: <199604172323.IAA10788@genesis.atrad.adelaide.edu.au> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith says: >> >> Thomas J Balfe stands accused of saying: >> > >> > Is it safer to run xdmcp or rexecd? I want to have some of my >> > machintoshes have access to a machine of mine for X. I am assuming that >> > rsh is the wrong way to go about it. >> >> Correct. xdmcp is good. >> If you need to up the level of security you can use DES authentication (via xdmcp) with the -cookie option on your X server. However, you will need to recompile your X world under FreeBSD as the standard X binary release does not support it. Chris From owner-freebsd-security Fri Apr 19 01:30:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA08606 for security-outgoing; Fri, 19 Apr 1996 01:30:11 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA08596 for ; Fri, 19 Apr 1996 01:30:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id BAA17444 for ; Fri, 19 Apr 1996 01:29:42 -0700 (PDT) Prev-Resent: Fri, 19 Apr 1996 01:29:42 -0700 Prev-Resent: "security@freebsd.org " Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id XAA17140 for ; Thu, 18 Apr 1996 23:28:27 -0700 (PDT) Received: from bbnplanet.com (poblano.near.net [198.114.157.116]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id SAA07903 for ; Thu, 18 Apr 1996 18:59:22 -0700 Received: from poblano.near.net by poblano.bbnplanet.com id aa05039; 18 Apr 96 15:14 EDT Received: from why.cert.org by poblano.bbnplanet.com id aa05010; 18 Apr 96 14:58 EDT Received: (from cert-advisory@localhost) by why.cert.org (8.6.12/CERT-ecd.1) id OAA19137 for cert-advisory-queue-1; Thu, 18 Apr 1996 14:51:47 -0400 Date: Thu, 18 Apr 1996 14:51:47 -0400 Message-Id: <199604181851.OAA19137@why.cert.org> From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-96.08 - Vulnerabilities in PCNFSD Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 Resent-To: security@freebsd.org Resent-Date: Fri, 19 Apr 1996 01:29:42 -0700 Resent-Message-ID: <17442.829902582@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ============================================================================= CERT(sm) Advisory CA-96.08 April 18, 1996 Topic: Vulnerabilities in PCNFSD ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of two vulnerabilities in the pcnfsd program (pcnfsd is also known as rpc.pcnfsd); we have also received reports that these problems are being exploited. These vulnerabilities are present in some vendor-provided versions of pcnfsd and in some publicly available versions. These two vulnerabilities were reported by Avalon Security Research in reports entitled "pcnfsd." If you are using a vendor-supplied version of pcnfsd, please see the vendor information in Section III.A and Appendix A. Until you can install a patch from your vendor for these vulnerabilities, consider using the publicly available version described in Section III.B. If you already use or plan to switch to a public version, we urge you to use the version cited in Section III.B or install the patch described in Section III.C. This patch has already been incorporated into the pcnfsd version described in III.B. There are many different public domain versions of pcnfsd, and we have not analyzed the vulnerability of those versions. We have analyzed and fixed the problems noted in this advisory only in the version described in III.B. As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-96.08.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The pcnfsd program (also called rpc.pcnfsd) is an authentication and printing program that runs on a UNIX server. There are many publicly available versions, and several vendors supply their own version. pcnfsd supports a printing model that uses NFS to transfer files from a client to the pcnfsd server. (Note: pcnfsd does *not* provide NFS services.) When a client wants to print a file, it requests the path to a spool directory from the server. The client then writes the necessary files for printing using NFS, and informs the pcnfsd server that the files are ready for printing. pcnfsd creates a subdirectory for each of its clients using the client's hostname, then returns this path name to the client. The returned path name must be exported via to its clients by the NFS server. The NFS server and the pcnfsd server may be two separate machines. The first vulnerability is that pcnfsd, which runs as root, creates the aforementioned directories with mkdir(2) and then changes their mode with chmod(2) to mode 777. If the target directory is replaced with a symbolic link pointing to a restricted file or directory, the mkdir(2) will fail but the chmod(2) will succeed. This means that the target of the symbolic link will be mode 777. Note that pcnfsd must run as root when servicing print requests so that it can assume the identity of the PC user when interacting with UNIX print commands. On some systems, pcnfsd may also have to run as root so it can read restricted files when carrying out authentication tasks. The second vulnerability is that pcnfsd calls the system(3) subroutine as root, and the string passed to system(3) can be influenced by the arguments given in the remote procedure call. Remote users can execute arbitrary commands on the machine where pcnfsd runs. II. Impact For the first vulnerability, local users can change the permissions on any file accessible to the local system that the root user can change. For the second vulnerability, remote users can execute arbitrary commands as root on the machine where pcnfsd runs. III. Solution If you are using pcnfsd from a vendor, consult the vendor list in Section A. If your vendor is not listed, we recommend that you contact your vendor directly. Until a vendor patch is available, we recommend that you obtain the publicly available version of pcnfsd as described in Section B. This version already has the patch described in Section C. If you are presently using a public version of pcnfsd, we recommend that you either change to the version listed in Section B or apply the patch described in Section C. (The version in Section B already contains this patch.) A. Obtain and install the appropriate patch according to the instructions included with the patch. Below is a list of the vendors who have reported to us as of the date of this advisory. More complete information, including how to obtain patches, is provided in the appendix of this advisory and reproduced in the CA-96.xx.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 or Source Status ---------------- ------------ BSDI BSD/OS Vulnerable. Patch available. Hewlett Packard Vulnerable. Patch under development. IBM AIX 3.2 Vulnerable. Patches available. IBM AIX 4.1 Vulnerable. Patches available. NEXTSTEP Vulnerable. Will be fixed in version 4.0. SCO OpenServer 5 Vulnerable. Patch under development. SCO UnixWare 2.1 Vulnerable. Patch under development. SGI IRIX 5.3 Vulnerable. Patch under development. SGI IRIX 6.2 Not vulnerable. B. Until you are able to install the appropriate patch, we recommend that you obtain a version of pcnfsd from one of the following locations. This version already has the patch mentioned in Section III.C and included in Appendix B. ftp://ftp.cert.org/pub/tools/pcnfsd/pcnfsd.93.02.16-cert-dist.tar.Z ftp://ftp.cert.dfn.de/pub/tools/net/pcnfsd/pcnfsd.93.02.16-cert-dist.tar.Z MD5 (pcnfsd.93.02.16-cert-dist.tar.Z) = b7af99a07dfcf24b3da3446d073f8649 Build, install, and restart rpc.pcnfsd. Ensure that the mode of the top-level pcnfsd spool directory is 755. In this version of pcnfsd, the top level spool directory is /usr/spool/pcnfs. To change this to mode 755, do the following as root: chmod 755 /usr/spool/pcnfs C. Appendix B contains a patch for the two vulnerabilities described in this advisory. Apply the patch using the GNU patch utility or by hand as necessary. Rebuild, reinstall, and restart rpc.pcnfsd. Set the mode of the top-level pcnfsd spool directory to 755. For example, in the version of pcnfsd cited in Section B, the top level spool directory is /usr/spool/pcnfs. To change this to mode 755, do the following as root: chmod 755 /usr/spool/pcnfs --------------------------------------------------------------------------- The CERT Coordination Center thanks Josh D., Ben G., and Alfred H. of Avalon Security Research for providing information for this advisory. We thank Wolfgang Ley of DFN-CERT for his help in understanding these problems. --------------------------------------------------------------------------- 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 18, 1996 See CA-96.08.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. Berkeley Software Design, Inc. (BSDI) ===================================== The problem described in these vulnerabilities is present in all versions of BSD/OS. There is a patch (our patch number U210-007) for our 2.1 version of BSD/OS and associated products available from our patch and ftp servers or ftp://ftp.BSDI.COM/bsdi/patches/patches-2.1/U210-007 Hewlett-Packard Company ======================= Patches in process, watch for HP an security bulletin for this vulnerability. IBM Corporation =============== See the appropriate release below to determine your action. AIX 3.2 ------- Apply the following fixes to your system: APAR - IX57623 (PTF - U442633) APAR - IX56965 (PTF - U442638) To determine if you have these PTFs on your system, run the following commands: lslpp -lB U442633 lslpp -lB U442638 AIX 4.1 ------- Apply the following fixes to your system: APAR - IX57616 APAR - IX56730 To determine if you have these APARs on your system, run the following commands: instfix -ik IX57616 instfix -ik IX56730 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". IBM and AIX are registered trademarks of International Business Machines Corporation. NeXT Software, Inc. =================== NEXTSTEP is vulnerable. This will be fixed in the 4.0 release of OpenStep for Mach (aka NEXTSTEP 4.0, due out 2Q96). The Santa Cruz Operation, Inc. ============================== Patches for pcnfsd are currently being developed for the following releases: SCO OpenServer 5 SCO UnixWare 2.1. These releases, as well as all prior releases, are vulnerable to both issues mentioned in the advisory. Should you not need to use pcnfs, SCO recommends that you not run pcnfsd. This can be done by commenting out pcnfsd in the appropriate script that starts pcnfsd, located in /etc/rc2.d. The README file for this advisory will be updated when further patch information is available. Silicon Graphics Corporation ============================ pcnfsd was only released for IRIX 5.3 and IRIX 6.2. SGI is producing patch1179 for IRIX 5.3. IRIX 6.2 is not vulnerable. ......................................................................... Appendix B: Patch Information Here is the patch for pcnfsd_print.c. It is also available as: ftp://ftp.cert.org/pub/tools/pcnfsd/pcnfsd_print.c.diffs ftp://ftp.cert.dfn.de/pub/tools/net/pcnfsd/pcnfsd_print.c.diffs MD5 (pcnfsd_print.c-diffs) = ec44046ff5c769aa5bf2d8d155b61f1f ---------------------------------CUT HERE--------------------------------- *** /tmp/T0a002c1 Fri Apr 5 13:14:50 1996 --- pcnfsd_print.c Fri Apr 5 13:14:46 1996 *************** *** 221,226 **** --- 221,227 ---- { int dir_mode = 0777; int rc; + mode_t oldmask; *sp = &pathname[0]; pathname[0] = '\0'; *************** *** 231,241 **** /* get pathname of current directory and return to client */ (void)sprintf(pathname,"%s/%s",sp_name, sys); (void)mkdir(sp_name, dir_mode); /* ignore the return code */ - (void)chmod(sp_name, dir_mode); rc = mkdir(pathname, dir_mode); /* DON'T ignore this return code */ if((rc < 0 && errno != EEXIST) || - (chmod(pathname, dir_mode) != 0) || (stat(pathname, &statbuf) != 0) || !(statbuf.st_mode & S_IFDIR)) { (void)sprintf(tempstr, --- 232,242 ---- /* get pathname of current directory and return to client */ (void)sprintf(pathname,"%s/%s",sp_name, sys); + oldmask = umask(0); (void)mkdir(sp_name, dir_mode); /* ignore the return code */ rc = mkdir(pathname, dir_mode); /* DON'T ignore this return code */ + umask(oldmask); if((rc < 0 && errno != EEXIST) || (stat(pathname, &statbuf) != 0) || !(statbuf.st_mode & S_IFDIR)) { (void)sprintf(tempstr, *************** *** 381,387 **** ** filter with the appropriate arguments. **------------------------------------------------------ */ ! (void)run_ps630(new_pathname, opts); } /* ** Try to match to an aliased printer --- 382,391 ---- ** filter with the appropriate arguments. **------------------------------------------------------ */ ! (void)sprintf(tempstr, ! "rpc.pcnfsd: ps630 filter disabled for %s\n", pathname); ! msg_out(tempstr); ! return(PS_RES_FAIL); } /* ** Try to match to an aliased printer ---------------------------------CUT HERE--------------------------------- From owner-freebsd-security Sat Apr 20 11:53:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA23365 for security-outgoing; Sat, 20 Apr 1996 11:53:51 -0700 (PDT) Received: from optim.ism.net (optim.ism.net [205.199.12.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA23359 Sat, 20 Apr 1996 11:53:48 -0700 (PDT) Received: from optim.ism.net (jdc@optim.ism.net [205.199.12.2]) by optim.ism.net (8.6.12/8.6.12) with SMTP id NAA28806; Sat, 20 Apr 1996 13:01:53 -0600 Date: Sat, 20 Apr 1996 13:01:52 -0600 (MDT) From: John-David Childs To: freebsd-questions@freebsd.org cc: freebsd-security@freebsd.org Subject: uucpd: passwd read Undefined error 0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running 2.1.0-RELEASE on a remote machine and found the following message this morning: /etc>grep uucp /var/log/messages Apr 20 11:37:48 deimos uucpd[16164]: passwd read: Undefined error: 0 Apr 20 11:53:55 deimos uucpd[16238]: passwd read: Undefined error: 0 Since I am not (yet) offering UUCP services on this particular box, I have since disabled uucpd in /etc/inetd (stupid me, I forgot to check that when I installed FreeBSD. However, I also noticed the following in my /var/log/user.log Apr 20 11:38:11 Apr 20 11:38:14 last message repeated 10 times /etc/syslog is set so that user.* goes to /var/log/user.log I am assuming that tried to get some sort of password list from my FreeBSD box (waste of time, really, since there are no user files on it ;-). Any clues appreciated. -- John-David Childs www.marsweb.com/www.ism.net System Administrator Internet Services Montana (406)721-6277 & Network Engineer M@RSWeb - Montana's PREMIER Web Site "I used up all my sick days...so I'm calling in dead"