From owner-freebsd-security Mon Jul 8 07:17:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA06452 for security-outgoing; Mon, 8 Jul 1996 07:17:08 -0700 (PDT) Received: from biblioteca.campus.unal.edu.co ([200.21.26.198]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA06442 for ; Mon, 8 Jul 1996 07:17:00 -0700 (PDT) Received: by biblioteca.campus.unal.edu.co (AIX 3.2/UCB 5.64/4.03) id AA16318; Mon, 8 Jul 1996 09:25:56 -0400 Date: Mon, 8 Jul 1996 09:25:56 -0400 (EDT) From: "Pedro F. Giffuni S." To: security@freebsd.org Subject: sendmail under control Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks for the excellent suggestions about the sendmail hole. Can sendmail be runned as a user without changing permissions to all the mail subdirectories? Some special "mail" user ? Pedro. From owner-freebsd-security Tue Jul 9 02:27:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22423 for security-outgoing; Tue, 9 Jul 1996 02:27:57 -0700 (PDT) Received: from freebsd.gaffaneys.com ([134.129.252.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22303; Tue, 9 Jul 1996 02:27:40 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.6.12/8.6.12) id EAA05027; Tue, 9 Jul 1996 04:28:25 -0500 To: Garrett Wollman Cc: James Raynard , freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: What's up with ownership? References: <87n31da1pa.fsf@freebsd.gaffaneys.com> <199607062246.WAA03437@jraynard.demon.co.uk> <9607081500.AA03598@halloran-eldar.lcs.mit.edu> From: Zach Heilig Date: 09 Jul 1996 04:28:24 -0500 In-Reply-To: Garrett Wollman's message of Mon, 8 Jul 1996 11:00:39 -0400 Message-ID: <873f31ai87.fsf@freebsd.gaffaneys.com> Lines: 69 X-Mailer: Gnus v5.2.32/Emacs 19.31 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman writes: > It's worth explaining why this is the Right Thing. Say John and Jane > are working on a project together. To make file-sharing easier, they > create a group, `jjproj', and a directory, `/home/jjproj', mode > ug=rwx,o=rx, owner `root', group `jjproj', and agree to use a umask of > 002. My real problem isn't with files being created with a gid the same as the parent directory, at least after I thought it through a bit. It is really with an extraneous warning from mv(1) while trying to preserve that gid (which, in this case, you are not a member of) in some other directory. The only time I think it would be appropriate for mv(1) to complain that it can't preserve the gid is when either the group write and/or setgid bits are set. It should complain about not preserving the uid when the setuid bit is set. In either case, neither the setuid or the setgid bits should be preserved. mv(1) will currently retain the setuid bit no matter what the situation. > Consider by contrast the BSD model. John creates `/home/jjproj/foo', > and it automatically belongs to the same group as is able to write to > the `/home/jjproj' directory in the first place, which is exactly the > right thing. Rather than introduce warts to selectively enable this > behavior depending on some random selection of circumstances, BSD > simply applies this model consistently throughout the filesystem, even > in places where it is not obviously useful. The problem, I think, is really mv, not the system. BTW, I did find a real bug in mv, and a potential security hole (which is why I cross-mailed it to security). I think this only works if the two directories are on different filesystems. Try this on your machine: Script started on Tue Jul 9 03:50:45 1996 $ whoami user1 $ pwd /usr/home/user1 $ mkdir foo $ chmod 777 foo $ cd foo $ touch bar $ chmod 6755 bar $ ls -l bar -rwsr-sr-x 1 user1 user 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:14 1996 Script started on Tue Jul 9 03:51:24 1996 $ whoami user2 $ cd /tmp $ mv ~user1/foo/bar . mv: ./bar: set owner/group: Operation not permitted mv: ./bar: set mode: Operation not permitted $ ls -l bar -rwsr-xr-x 1 user2 wheel 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:39 1996 Since mv cannot preserve the uid, it SHOULD NOT preserve the setuid bit. I sent a problem report for this one. I unfortunately removed all the base sources from my machine since 2.1.5-RELEASE should be out soon. -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited >commercial< email is subject to a $100 proof-reading fee. From owner-freebsd-security Tue Jul 9 12:02:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28363 for security-outgoing; Tue, 9 Jul 1996 12:02:00 -0700 (PDT) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA28358; Tue, 9 Jul 1996 12:01:56 -0700 (PDT) Received: by sequent.kiae.su id AA04585 (5.65.kiae-2 ); Tue, 9 Jul 1996 22:55:51 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 9 Jul 96 22:55:51 +0400 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id WAA00325; Tue, 9 Jul 1996 22:52:40 +0400 (MSD) Message-Id: <199607091852.WAA00325@nagual.ru> Subject: It is impossible even for root to make core from [sg]uid process! To: current@freebsd.org (FreeBSD-current) Date: Tue, 9 Jul 1996 22:52:40 +0400 (MSD) Cc: security@freebsd.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL22 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As subject says, it is impossible even for root to debug [sg]uid program (especially daemon) without core from it. Following block from kern_sig.c stops core dump: /* * If we are setuid/setgid, or if we've changed uid's in the past, * we may be holding privileged information. We must not core! */ if (pcred->p_svuid != pcred->p_ruid || pcred->p_svgid != pcred->p_rgid) return (EFAULT); if (p->p_flag & P_SUGID) return (EFAULT); IMHO this code restricts too much: the only case it is needed for is uid 0 -> user_id transaction. It is NOT needed for user_id -> 0 transaction, because core file can be owned by root in this case with 0600 permissions. I want to frame this block: if (pcred->p_ruid) { /* non-root case */ [block] } else { /* root case */ euid = 0; /* to make program.core owned by root, 0600 */ } This fix allows core from most of daemons, because they usually started by root (ruid == 0). Any comments? -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Tue Jul 9 13:14:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA03226 for security-outgoing; Tue, 9 Jul 1996 13:14:15 -0700 (PDT) Received: from saatel.shiny.it (saatel.shiny.it [194.20.236.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA03204 for ; Tue, 9 Jul 1996 13:14:02 -0700 (PDT) Received: (from ace@localhost) by saatel.shiny.it (8.6.11/8.6.9) id WAA27313; Tue, 9 Jul 1996 22:01:10 +0200 Date: Tue, 9 Jul 1996 22:01:08 +0200 (MET DST) From: Angelo Cellai To: freebsd-security@freebsd.org Subject: stop your mail please! 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 i know this is not the right way to unsubscribe, but i unsubscribed as indicated on freebsd pages a lot of times, like ace@saatel.it and like ace@saatel.shiny.it but the robot of freebsd.org never accepted my unsubscription. i'm very bored about receiving such as 50/100 msgs every day about something that i'm no more interested on. eliminate my name from your mailing list or use a robo-mail that work better, THANKS. Regards ACe From owner-freebsd-security Tue Jul 9 14:34:22 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA09474 for security-outgoing; Tue, 9 Jul 1996 14:34:22 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA09452 for ; Tue, 9 Jul 1996 14:34:17 -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 OAA16884 for freebsd-security@freebsd.org; Tue, 9 Jul 1996 14:34:14 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199607092134.OAA16884@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.13 - Vulnerability in the dip program Date: Tue, 09 Jul 96 14:34:14 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I believe that the dip program used under FreeBSD is the same program as described below. We're probably 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 Return-Path: cert-advisory-request@cert.org Delivery-Date: Tue, 09 Jul 96 14:30:11 -0700 Return-Path: cert-advisory-request@cert.org Received: from orca.gov.bc.ca (ORCA.gov.bc.ca [142.32.102.25]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id OAA16819 for ; Tue, 9 Jul 1996 14:30:10 -0700 (PDT) Received: from why.cert.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA19326; Tue, 9 Jul 1996 14:30:04 -0700 Received: (from cert-advisory@localhost) by why.cert.org (8.6.12/CERT-ecd.1) id NAA05679 for cert-advisory-queue-4; Tue, 9 Jul 1996 13:22:14 -0400 Date: Tue, 9 Jul 1996 13:22:14 -0400 Message-Id: <199607091722.NAA05679@why.cert.org> From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-96.13 - Vulnerability in the dip program Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 - -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT(sm) Advisory CA-96.13 July 9, 1996 Topic: Vulnerability in the dip program - - ----------------------------------------------------------------------------- The CERT Coordination Center has received several reports of exploitations of a vulnerability in the dip program on Linux systems. The dip program is shipped with most versions of the Linux system; and versions up to and including version 3.3.7n are vulnerable. An exploitation script for Linux running on X86-based hardware is publicly available. Although exploitation scripts for other architectures and operating systems have not yet been found, we believe that they could be easily developed. The CERT Coordination Center recommends that you disable dip and re-enable it only after you have installed a new version. Section III below describes how to do that. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-96.13.README We encourage you to check our README files regularly for updates on advisories that relate to your site. - - ----------------------------------------------------------------------------- I. Description dip is a freely available program that is included in most distributions of Linux. It is possible to build it for and use it on other UNIX systems. The dip program manages the connections needed for dial-up links such as SLIP and PPP. It can handle both incoming and outgoing connections. To gain access to resources it needs to establish these IP connections, the dip program must be installed as set-user-id root. A vulnerability in dip makes it possible to overflow an internal buffer whose value is under the control of the user of the dip program. If this buffer is overflowed with the appropriate data, a program such as a shell can be started. This program then runs with root permissions on the local machine. Exploitation scripts for dip have been found running on Linux systems for X86 hardware. Although exploitation scripts for other architectures and operating systems have not yet been found, we believe that they could be easily developed. II. Impact On a system that has dip installed as set-user-id root, anyone with access to an account on that system can gain root access. III. Solution Follow the steps in Section A to disable your currently installed version of dip. Then, if you need the functionality that dip provides, follow the steps given in Section B. A. Disable the presently installed version of dip. As root, chmod 0755 /usr/sbin/dip By default, dip is installed in the /usr/sbin directory. Note that it may be installed elsewhere on your system. B. Install a new version of dip. If you need the functionality that dip provides, retrieve and install the following version of the source code for dip, which fixes this vulnerability. dip is available from ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz.sig MD5 (dip337o-uri.tgz) = 45fc2a9abbcb3892648933cadf7ba090 SHash (dip337o-uri.tgz) = 6e3848b9b5f9d5b308bbac104eaf858be4dc51dc - - --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Uri Blumenthal for his solution to the problem and Linux for their support in the development of this 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 (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. This file: ftp://info.cert.org/pub/cert_advisories/CA-96.13.dip_vul http://www.cert.org click on "CERT Advisories" - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMeJzdXVP+x0t4w7BAQEJdAQAt0Y9zXDjpeuRYFI+vmceXpHL8QJPm1GL zArG5qhGx5+9hTioQCUiq/kl6uXMI0IAbfdwDG3I0wg5i7Jvi8PLYyDujpl8+gVT jzJFEQ/S9CjZ6LUxzo2Twg90urQrphFzwnY4L5DVEftKaoL1zCpg6i4SadC7vQUm n0HWkh7kV4M= =zcQN - -----END PGP SIGNATURE----- ------- End of Forwarded Message From owner-freebsd-security Tue Jul 9 15:21:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13071 for security-outgoing; Tue, 9 Jul 1996 15:21:23 -0700 (PDT) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA13047 for ; Tue, 9 Jul 1996 15:21:11 -0700 (PDT) Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-2) with ESMTP id XAA29144; Tue, 9 Jul 1996 23:20:56 +0100 (BST) To: cschuber@orca.gov.bc.ca cc: freebsd-security@FreeBSD.ORG From: "Gary Palmer" Subject: Re: CERT Advisory CA-96.13 - Vulnerability in the dip program In-reply-to: Your message of "Tue, 09 Jul 1996 14:34:14 PDT." <199607092134.OAA16884@passer.osg.gov.bc.ca> Date: Tue, 09 Jul 1996 23:20:55 +0100 Message-ID: <29141.836950855@palmer.demon.co.uk> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Cy Schubert - ITSD Open Systems Group wrote in message ID <199607092134.OAA16884@passer.osg.gov.bc.ca>: > I believe that the dip program used under FreeBSD is the same program as > described below. We're probably vulnerable. Apparently not. We don't have `dip' in our base system (we use `tip' and `cu', the more traditional (if they could be called that) interfaces. The `dip' port isn't based on the linux one, and from the package that was on the 2.1.0-RELEASE CDROM: -r-xr-xr-x bin/bin 36864 Oct 7 00:33 1995 sbin/dip -r-xr-xr-x bin/bin 0 Oct 7 00:33 1995 sbin/diplogin link to sbin/dip ^ ^ Note the distinct lack of SUID bits ... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-security Tue Jul 9 17:09:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA19666 for security-outgoing; Tue, 9 Jul 1996 17:09:56 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19639 for ; Tue, 9 Jul 1996 17:08:36 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id UAA05135 for ; Tue, 9 Jul 1996 20:08:28 -0400 (EDT) Date: Tue, 9 Jul 1996 20:08:28 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L Subject: sudo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What are people's feelings towards the "sudo" utility? Is it really all that usefull, or does it just open up a lot of potential avenues of attack and abuse? Some of our co-located customers want to have it installed so they can do some root-privileged stuff, instead of getting us to do it all the time (even though that's what they pay us to do). -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Jul 9 18:13:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA22658 for security-outgoing; Tue, 9 Jul 1996 18:13:13 -0700 (PDT) Received: from mailhub.ASG.unb.ca ([198.164.16.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA22623 for ; Tue, 9 Jul 1996 18:12:02 -0700 (PDT) Received: from angus.ASG.unb.ca by mailhub.ASG.unb.ca (AIX 3.2/UCB 5.64/4.03) id AA40953; Tue, 9 Jul 1996 22:11:54 -0300 Date: Tue, 9 Jul 1996 22:11:54 -0300 (ADT) From: Peter Howlett To: Brian Tao Cc: FREEBSD-SECURITY-L Subject: Re: sudo 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 Tue, 9 Jul 1996, Brian Tao wrote: > What are people's feelings towards the "sudo" utility? Is it > really all that usefull, or does it just open up a lot of potential > avenues of attack and abuse? Some of our co-located customers want to > have it installed so they can do some root-privileged stuff, instead > of getting us to do it all the time (even though that's what they pay > us to do). We use sudo here at the office. It can be useful, but you do have to be _very_ careful with it. Allowing someome to sudo a vi session for instance grants root access. (:!/bin/sh) There are of course many other more obscure ways of getting a root shell as well, depending on what you allow in the sudoers file. We've seen people even sudoing shell scripts that are world writable for instance. As far as security holes are concerned, I have not heard of any, but that doesnt mean they dont exist... We use sudo more to keep our less educated users from requiring root for basic things like enabling the print queues on the office printers, etc... Its also handy for allowing regular admins to use their own shells and environments for doing root type things if you can sudo a shell. I personally wouldnt use it on a machine that has the possiblity of housing accounts of questionable intergrity. Its easy to not be paying enough attention to it, especially if you are a busy admin (is there any other kind?) -------------------------------------------------------------------- Peter Howlett Atlantic Systems Group E-Mail: Peter.Howlett@ASG.unb.ca Fredericton, N.B. Canada http://www.ASG.unb.ca/personal/ph.html Phone: (506) 447-3050 PGP Key ID: 60F2EEC1 Fax: (506) 453-5004 From owner-freebsd-security Tue Jul 9 19:15:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA26922 for security-outgoing; Tue, 9 Jul 1996 19:15:32 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA26916 for ; Tue, 9 Jul 1996 19:15:28 -0700 (PDT) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0udoo4-0008s7C; Tue, 9 Jul 96 19:15 PDT Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: sudo To: taob@io.org (Brian Tao) Date: Tue, 9 Jul 1996 19:15:12 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Jul 9, 96 08:08:28 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings towards the "sudo" utility? It's indispensable. -- Alan Batie ______ We're Starfleet officers: batie@agora.rdrop.com \ / Weird is part of the job. +1 503 452-0960 \ / --Captain Janeway DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Tue Jul 9 19:35:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28234 for security-outgoing; Tue, 9 Jul 1996 19:35:39 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA28222 for ; Tue, 9 Jul 1996 19:35:33 -0700 (PDT) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0udp7X-0008s7C; Tue, 9 Jul 96 19:35 PDT Message-Id: From: batie@agora.rdrop.com (Alan Batie) Subject: Re: sudo To: phowlett@ASG.unb.ca (Peter Howlett) Date: Tue, 9 Jul 1996 19:35:18 -0700 (PDT) Cc: taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "Peter Howlett" at Jul 9, 96 10:11:54 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > We use sudo here at the office. It can be useful, but you do have > to be _very_ careful with it. To expand a little on my earlier terse comment :-) I only allow access to it for people I trust as root users; one is allowed to run a script that creates a particular class of users, and I think it's secure, but even so it's someone I trust. The thing I don't trust is my ability to be certain that a program doesn't have back doors in it. The reason I call it indispensable is because I use it all the time. I get dozens of 5-second root-only requests/interrupts/things-that-need-done a day, and the other option is having a root window open all the time, and even that's not as convenient. -- Alan Batie ______ We're Starfleet officers: batie@agora.rdrop.com \ / Weird is part of the job. +1 503 452-0960 \ / --Captain Janeway DE 3C 29 17 C0 49 7A 27 \/ 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-security Tue Jul 9 22:42:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10586 for security-outgoing; Tue, 9 Jul 1996 22:42:46 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA10581 for ; Tue, 9 Jul 1996 22:42:44 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id WAA06366; Tue, 9 Jul 1996 22:42:42 -0700 From: Nathan Lawson Message-Id: <199607100542.WAA06366@kdat.calpoly.edu> Subject: Re: sudo To: taob@io.org (Brian Tao) Date: Tue, 9 Jul 1996 22:42:41 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: from "Brian Tao" at Jul 9, 96 08:08:28 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 > What are people's feelings towards the "sudo" utility? Is it > really all that usefull, or does it just open up a lot of potential > avenues of attack and abuse? Some of our co-located customers want to > have it installed so they can do some root-privileged stuff, instead > of getting us to do it all the time (even though that's what they pay > us to do). Sudo is useful for a lot of situations, but remember it is equivalent to giving said user a uid of zero. There is no way to keep a user with sudo access from getting root. As long as you remember that, you're ok. Second, something you said bothers me. They want to do root stuff even though you are paid to do that. Be very careful here with responsibility. What happens when they call you up complaining that no one but root can run commands? How long will it take you to find that the customer accidentally did a chmod 700 /? (actual case). What if it's something more subtle? Are you and they willing to accept the fact that it might take you extra time and/or money to clean up after them? Lastly, be careful what version of sudo you get. The version distributed a while back (and included in a popular sysadmin book!) used popen() to send mail when a user wasn't in the sudoers file. Hey, then you can put yourself in the sudoers file.. a feature! -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Tue Jul 9 23:05:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13076 for security-outgoing; Tue, 9 Jul 1996 23:05:55 -0700 (PDT) Received: from chloe.dmv.com (root@chloe.dmv.com [206.30.64.31]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA13071; Tue, 9 Jul 1996 23:05:51 -0700 (PDT) Received: (from patrick@localhost) by chloe.dmv.com (8.6.12/8.6.12) id CAA00518; Wed, 10 Jul 1996 02:05:13 -0400 Date: Wed, 10 Jul 1996 02:05:12 -0400 (EDT) From: Patrick To: Gary Palmer cc: cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org Subject: Re: CERT Advisory CA-96.13 - Vulnerability in the dip program In-Reply-To: <29141.836950855@palmer.demon.co.uk> 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 tried to use the code that I have that exploits the bug in the linux version, and it fails. The code takes advantage of overrunning the buffer in do_chatkey(). I looked through the BSD source and couldn't find a reference to do_chatkey(). ------------------------------------------------------------------------------ Patrick - Systems Administrator patrick@dmv.com DelMarVa OnLine! - Salisbury, MD On Tue, 9 Jul 1996, Gary Palmer wrote: > Cy Schubert - ITSD Open Systems Group wrote in message ID > <199607092134.OAA16884@passer.osg.gov.bc.ca>: > > I believe that the dip program used under FreeBSD is the same program as > > described below. We're probably vulnerable. > > Apparently not. We don't have `dip' in our base system (we use `tip' > and `cu', the more traditional (if they could be called that) > interfaces. The `dip' port isn't based on the linux one, and from the > package that was on the 2.1.0-RELEASE CDROM: > > -r-xr-xr-x bin/bin 36864 Oct 7 00:33 1995 sbin/dip > -r-xr-xr-x bin/bin 0 Oct 7 00:33 1995 sbin/diplogin link to sbin/dip > > ^ ^ > Note the distinct lack of SUID bits ... > > Gary > -- > Gary Palmer FreeBSD Core Team Member > FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info > From owner-freebsd-security Wed Jul 10 07:33:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14805 for security-outgoing; Wed, 10 Jul 1996 07:33:41 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14798 for ; Wed, 10 Jul 1996 07:33:36 -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 HAA18963; Wed, 10 Jul 1996 07:33:22 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199607101433.HAA18963@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: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: sudo In-reply-to: Your message of "Tue, 09 Jul 96 20:08:28 EDT." Date: Wed, 10 Jul 96 07:33:22 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings towards the "sudo" utility? Is it > really all that usefull, or does it just open up a lot of potential > avenues of attack and abuse? Some of our co-located customers want to > have it installed so they can do some root-privileged stuff, instead > of getting us to do it all the time (even though that's what they pay > us to do). Where I work we use it all the time. We use it mainly internally within the Open Systems Group (people who would normally have the root password anyway). The root passwords are normally not used and are stored in an envelope in the security services office. We currently have only one client who requires sudo to mount a number of VM/ESA minidisks on a Sun box to load a DB2 database. In this case a we have built some code to prompt the user for various VM specific mount options. The code only allows them to mount VM minidisks from two VM machines on our raised floor. I have seen indiscriminate use of sudo which will compromise a system. For example, vi and more. Granting sudo access to vi is an obvious hole but more is a little subtle. Since you can shell escape in more, granting access to more would grant the user a root shell. To make effective use of sudo with a help desk, for example, you would need to build code to perform the required function while restricting the user's access to other functions. For example, if you wish to have your helpdesk alter end-user's dot files when when your users call in for help, you could create some code to copy the user's dot file to a work area, via sudo, then edit the dot file in the work area, under the help desk person's own id, and finally copy the working copy of the dot file from the work area to the user's home directory. Your code would contain checks to ensure that only end-user's dot files can be updated, not the files of system administration staff. In short, granting root privilege via sudo takes a lot of planning to ensure that all potential security holes are plugged. > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) > Systems and Network Administrator, Internet Canada Corp. > "Though this be madness, yet there is method in't" > 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." From owner-freebsd-security Thu Jul 11 08:00:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA17059 for security-outgoing; Thu, 11 Jul 1996 08:00:17 -0700 (PDT) Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA16073; Thu, 11 Jul 1996 07:56:40 -0700 (PDT) Received: from a8-p2-zg.tel.hr [205.219.255.145] by jagor.srce.hr (8.7.5/8.6.12.CI) id QAA06595; Thu, 11 Jul 1996 16:56:09 +0200 (MET DST) Message-ID: <31E51772.188D@jagor.srce.hr> Date: Thu, 11 Jul 1996 17:02:10 +0200 From: Sinisa Sehovic X-Mailer: Mozilla 3.0b3 (Win95; I) MIME-Version: 1.0 To: announce@freebsd.org CC: hackers@freebsd.org, questions@freebsd.org, bugs@freebsd.org, current@freebsd.org, security@freebsd.org, ports@freebsd.org Subject: unsubscribe Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-security Thu Jul 11 08:11:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20061 for security-outgoing; Thu, 11 Jul 1996 08:11:38 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA20008; Thu, 11 Jul 1996 08:11:29 -0700 (PDT) Received: by sovcom.kiae.su id AA00328 (5.65.kiae-1 ); Thu, 11 Jul 1996 17:57:53 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 11 Jul 96 17:57:53 +0300 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id SAA02660; Thu, 11 Jul 1996 18:55:15 +0400 (MSD) Message-Id: <199607111455.SAA02660@nagual.ru> Subject: POSIX saved ids: what to do? To: security@freebsd.org, core@freebsd.org, bde@zeta.org.au (Bruce Evans) Date: Thu, 11 Jul 1996 18:55:14 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL22 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk POSIX saved ids (when turned on) is incompatible with standard BSD semantics which is close to POSIX saved ids turned off. I.e. seteuid + setuid sequence produce very different result in both models. Old or BSD programs which use it may even not know about POSIX saved ids. So I can see here two solutions: 1) Completely return to old BSD semantics which is close to POSIX saved ids turned off. 2) Return to old BSD semantics when program issue seteuid() or setreuid() first time (POSIX allows only setuid so it clearly indicates non-POSIX model). Comments? -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Thu Jul 11 11:27:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA23900 for security-outgoing; Thu, 11 Jul 1996 11:27:02 -0700 (PDT) Received: from E-MAIL.COM (e-mail.com [199.171.26.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA23895 for ; Thu, 11 Jul 1996 11:27:01 -0700 (PDT) Received: from IMXGATE.COM by E-MAIL.COM (IBM VM SMTP V2R3) with BSMTP id 0678; Thu, 11 Jul 96 14:27:05 EDT Received: from sv13.cis.squared.com by imxgate.com (IBM VM SMTP V2R3) with TCP; Thu, 11 Jul 96 14:27:02 EDT Received: from mg01a.mhs.squared.com by sv13.cis.squared.com (AIX 4.1/UCB 5.64/4.03) id AA52172; Thu, 11 Jul 1996 14:26:55 -0400 Received: from NetWare MHS (SMF70) by mg01a.mhs.squared.com via Connect2-SMTP 4.00.b27D; Thu, 11 Jul 1996 14:25:18 -0400 Message-Id: <2979895B0187397C@mg01a.mhs.squared.com> Date: Thu, 11 Jul 1996 14:27:16 -0400 From: "Sexton, Robert" Organization: Square D To: freebsd-security@freefall.FreeBSD.org Subject: Password mechanisms. Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Mailer: Connect2-SMTP 4.00.b27D MHS to SMTP Gateway Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I realize that kerberos has been integrated into BSD4.4. Where does that leave the old fashioned /etc/passwd file? I recently locked myself out my FreeBSD system, and I was puzzled as to why I could not de-password root, no matter what I tried There was something strange about clearing the password out of /etc/shadow, and being ignored. I know this stuff is there somewhere.. And more importantly, how would I backup account information? Thanks, Robert Sexton. From owner-freebsd-security Thu Jul 11 13:31:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02056 for security-outgoing; Thu, 11 Jul 1996 13:31:24 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02047 for ; Thu, 11 Jul 1996 13:31:16 -0700 (PDT) Received: from mom.hooked.net (mom.hooked.net [206.80.6.10]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with ESMTP id NAA16102 for ; Thu, 11 Jul 1996 13:03:00 -0700 (PDT) Received: from s29.netgate.net (s29.netgate.net [205.214.175.29]) by mom.hooked.net (8.7.4/8.7.3) with SMTP id MAA12375; Thu, 11 Jul 1996 12:56:53 -0700 (PDT) Message-ID: <31DC2239.7DA@netgate.net> Date: Thu, 04 Jul 1996 12:57:45 -0700 From: Matt Clark X-Mailer: Mozilla 2.02 (Win16; I) MIME-Version: 1.0 To: "Sexton, Robert" CC: freebsd-security@freefall.freebsd.org Subject: Re: Password mechanisms. References: <2979895B0187397C@mg01a.mhs.squared.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sexton, Robert wrote: > > I realize that kerberos has been integrated into BSD4.4. Where does that > leave the old fashioned /etc/passwd file? I recently locked myself out > my FreeBSD system, and I was puzzled as to why I could not de-password > root, no matter what I tried There was something strange about clearing Look in /etc/master.passwd --matt Clark From owner-freebsd-security Thu Jul 11 20:59:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27055 for security-outgoing; Thu, 11 Jul 1996 20:59:38 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA27050 for ; Thu, 11 Jul 1996 20:59:36 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA28671; Thu, 11 Jul 1996 23:59:17 -0400 (EDT) Date: Thu, 11 Jul 1996 23:59:17 -0400 (EDT) From: Brian Tao To: Dan Polivy cc: freebsd-security@FreeBSD.ORG Subject: Re: is FreeBSD's rdist vulnerable? 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, 3 Jul 1996, Dan Polivy wrote: > > Has anyone read 8lgm's rdist advisory and attempted to see whether or not > FreeBSD's rdist is vulnerable? I use rdist to update various files here, > and so I suppose getting id of the setuid bit would break it? Thanks... It is indeed vulnerable. I've mailed security-officer@freebsd.org the exploit so someone can fix it right away. 2.1.0R and all the 2.2 snapshots are vulnerable. I haven't tried any of the 2.1.5 releases. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Thu Jul 11 21:23:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28712 for security-outgoing; Thu, 11 Jul 1996 21:23:26 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA28704 for ; Thu, 11 Jul 1996 21:23:23 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA04487; Thu, 11 Jul 1996 22:23:07 -0600 (MDT) Date: Thu, 11 Jul 1996 22:23:07 -0600 (MDT) Message-Id: <199607120423.WAA04487@rocky.mt.sri.com> From: Nate Williams To: Brian Tao Cc: Dan Polivy , freebsd-security@freebsd.org Subject: Re: is FreeBSD's rdist vulnerable? In-Reply-To: References: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao writes: > On Wed, 3 Jul 1996, Dan Polivy wrote: > > > > Has anyone read 8lgm's rdist advisory and attempted to see whether or not > > FreeBSD's rdist is vulnerable? I use rdist to update various files here, > > and so I suppose getting id of the setuid bit would break it? Thanks... > > It is indeed vulnerable. I've mailed security-officer@freebsd.org > the exploit so someone can fix it right away. 2.1.0R and all the 2.2 > snapshots are vulnerable. I haven't tried any of the 2.1.5 releases. I *just* made some sprintf() -> snprintf() changes to current's rdist. If I sent you the patches could you check them out and see if it fixes the bug? They are pretty innocuous patches, and could be brought into -stable if it's not too late if it turns out they fix the bug. Nate From owner-freebsd-security Fri Jul 12 00:45:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA11113 for security-outgoing; Fri, 12 Jul 1996 00:45:42 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA11107 for ; Fri, 12 Jul 1996 00:45:38 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id JAA11190; Fri, 12 Jul 1996 09:44:54 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma011032; Fri Jul 12 09:44:01 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id JAA24023; Fri, 12 Jul 1996 09:46:18 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id JAA17299; Fri, 12 Jul 1996 09:43:59 +0200 From: Guido van Rooij Message-Id: <199607120743.JAA17299@spooky.lss.cp.philips.com> Subject: Re: Password mechanisms. To: sextonr.crestvie@squared.com (Sexton, Robert) Date: Fri, 12 Jul 1996 09:43:58 +0200 (MET DST) Cc: freebsd-security@freefall.freebsd.org Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: <2979895B0187397C@mg01a.mhs.squared.com> from "Sexton, Robert" at "Jul 11, 96 02:27:16 pm" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sexton, Robert wrote: > I realize that kerberos has been integrated into BSD4.4. Where does that > leave the old fashioned /etc/passwd file? I recently locked myself out > my FreeBSD system, and I was puzzled as to why I could not de-password > root, no matter what I tried There was something strange about clearing > the password out of /etc/shadow, and being ignored. I know this stuff is > there somewhere.. And more importantly, how would I backup account > information? Kerberos has nothing to do with it. In fact BSD uses a transparent shadow password system. The real stuff is stored in /etc/master.passwd. Note that you should edit it with vipw. Further, a running system uses pwd.db and spwd.db, the database equivalents of passwd and master.passwd. -Guido From owner-freebsd-security Fri Jul 12 08:47:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20586 for security-outgoing; Fri, 12 Jul 1996 08:47:12 -0700 (PDT) Received: from kechara.flame.org (kechara.flame.org [192.80.44.209]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA20580 for ; Fri, 12 Jul 1996 08:47:03 -0700 (PDT) Received: from zhaneel.flame.org (zhaneel.flame.org [192.80.44.210]) by kechara.flame.org (8.7.5/8.6.9) with ESMTP id LAA22005; Fri, 12 Jul 1996 11:46:37 -0400 (EDT) Received: (from explorer@localhost) by zhaneel.flame.org (8.7.5/8.6.9) id LAA07921; Fri, 12 Jul 1996 11:46:27 -0400 (EDT) To: "Sexton, Robert" Cc: freebsd-security@freefall.freebsd.org Subject: Re: Password mechanisms. References: <2979895B0187397C@mg01a.mhs.squared.com> From: Michael Graff Date: 12 Jul 1996 11:46:26 -0400 In-Reply-To: "Sexton, Robert"'s message of Thu, 11 Jul 1996 14:27:16 -0400 Message-ID: Lines: 19 X-Mailer: Gnus v5.2.33/Emacs 19.31 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Sexton, Robert" writes: > I realize that kerberos has been integrated into BSD4.4. Where does that > leave the old fashioned /etc/passwd file? I recently locked myself out Too bad there are two flaws in using Kerberos currently: (1) there is no way to disable it for specific accounts. It always tries Kerberos first, then local password entry, if there is one. (2) There is no way to specify remote realms for a user. For example, I might want spirit@MIT.EDU to be the realm to use for local account spirit, not spirit@FLAME.ORG. (3) It integrated Kerberos 4, which is going out eventually. IMHO, get Cygnus's Kerberos 4 or 5, and call that that. --Michael From owner-freebsd-security Fri Jul 12 11:29:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02775 for security-outgoing; Fri, 12 Jul 1996 11:29:11 -0700 (PDT) Received: from mercury.gaianet.net (root@mercury.gaianet.net [206.171.98.26]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA02770; Fri, 12 Jul 1996 11:29:09 -0700 (PDT) Received: (from jbhunt@localhost) by mercury.gaianet.net (8.7.5/8.6.12) id LAA03657; Fri, 12 Jul 1996 11:28:37 -0700 (PDT) Date: Fri, 12 Jul 1996 11:28:36 -0700 (PDT) From: jbhunt To: root@mercury.gaianet.net cc: freebsd-security-notification@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: ROOT COMPROMISE Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1536134556-837195972=:2906" Content-ID: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1536134556-837195972=:2906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Ok, I tracked down the offending account Vince. The account soulz has 2 setuid root shells in it at this moment. Fortunately for us this time this offender wasn't as smart as the last one and left us a trail. Included in this email are both of his history files the .historysoulz file is the one he used to gain root the historysoulz file is what he did after he got root. It seems that he telneted to io.com and downloaded a file called bsdiex. Then ran the file and it made a setuid shell called .irc. He seems to have been trying many different things to gain root such as dip and the other things. After the bsdiex file he compiled a file called real.c. I tracked that down on the system it is in the usr dir. So there may be something that ties them together. I have since called Ken Jackson,System's Manager, at io.com and he is going to help as much as he can. He is currently looking for the bsdiex file on his system. I have suspended the account. However it looks as tho he made 1 account while he was root and I am not sure exactly what it is. So Vince we may need to take some action on this. Give me your thoughts on what we might do. I would also appreciate some help on this from the freebsd guys. A few weeks ago when I posted saying there was a NEW exploit for freebsd nobody seemed to believe me however it seems there truely IS something new out here. Please give me your thoughts and ideas after looking at the files. John SysAdmin Gaianet --0-1536134556-837195972=:2906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=".history" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IyswODMzNDcyMjg0DQptYWlsDQojKzA4MzM0NzIzOTYNCmNkIGVnZ2Ryb3Ax LjBhDQojKzA4MzM0NzI0MTANCnBpY28gbXljcm9uDQojKzA4MzM0NzI1NzkN CmNyb250YWIgbXljcm9uDQojKzA4MzM0NzI2MDYNCnBpY28gYm90Y2hrDQoj KzA4MzM0Nzk5NzcNCmNkIGVnZ2RybzBhDQojKzA4MzM0ODAwMDANCmNkIGVn Z2Ryb3AxLjBhDQojKzA4MzM0ODAwMzQNCmJvdGNoaw0KIyswODMzNDgwNTg2 DQpkaXINCiMrMDgzMzQ4MDYwMw0KY2QgZWdnZHJvcDEuMGENCiMrMDgzMzQ4 MDYxMA0KcHMgLQ0KIyswODMzNDgwNjIyDQpwcyAteA0KIyswODMzNDgwNjM4 DQpraWxsIC05IC0xDQojKzA4MzM0ODA2NDMNCnBzDQojKzA4MzM0ODA2OTAN CmVnZ2Ryb3AgZndhDQojKzA4MzM0ODM2MDgNCmNkIGRyb3AxLjBhDQojKzA4 MzM0ODM2MjENCmNkIGVnZHJvcDEuMGENCiMrMDgzMzQ4MzY0MA0KY2QgZWdn ZHJvcDEuMGENCiMrMDgzMzQ4MzY5MA0KcHMgLXgNCiMrMDgzMzQ4MzcwNQ0K a2lsbCAtOSAtMQ0KIyswODMzNDgzOTA4DQplZ2dkcm9wDQojKzA4MzM0ODM5 MTUNCnBzDQojKzA4MzM0ODM5MjYNCmVnZ2Ryb3AgZndhDQojKzA4MzM0ODQ4 NDcNCnBzIC14DQojKzA4MzM0ODQ5NTMNCmtpbGwgLTkgLTENCiMrMDgzMzQ4 NTAwMA0KZWdnZHJvcCBmd2ENCiMrMDgzMzQ5MDA0Nw0KbWFpbA0KIyswODMz NTAxNDU0DQpjZCBlZ2dkcm9wMS4wYQ0KIyswODMzNTAxNDU5DQplZ2dkcm9w IGZ3YQ0KIyswODMzNTA0Nzk2DQptYWlsDQojKzA4MzM1MDQ4NDYNCmNkIGVn Z2Ryb3AxLjBhDQojKzA4MzM1MDQ4NTYNCmNkIHN2ZXJzDQojKzA4MzM1MDQ4 NzYNCmNkIHNlcnZlcnMNCiMrMDgzMzUwNDg4Mw0KY2Qgc2VydmVyDQojKzA4 MzM1MDQ4ODgNCmxzDQojKzA4MzM1MDQ5MzINCmNkDQojKzA4MzM1MDQ5NTgN CmNkIHNjaXB0cw0KIyswODMzNTA0OTcwDQpjZCBzY3JpcHRzDQojKzA4MzM1 MDQ5OTcNCnBpY28NCiMrMDgzMzUwNTE3MQ0KY2QgZWdnZHJvcDEuMGENCiMr MDgzMzUwNTIxNQ0KbHMNCiMrMDgzMzUwNTIyOA0Kc2NyaXB0cw0KIyswODMz NTA1Mjg5DQplZ2dkcm9wIGYNCiMrMDgzMzUwNTMwOA0KZWdnZHJvcCBmd2EN CiMrMDgzMzUwNzYxNA0KY2QgZWdnZHJvcDEuMGENCiMrMDgzMzUwNzYyNQ0K cHMgLXgNCiMrMDgzMzUwNzYzOA0Ka2lsbCAtOQ0KIyswODMzNTA3NjUyDQpl Z2dkciBmd2ENCiMrMDgzMzUwNzY2Nw0KZWdnZHJvcCBmd2ENCiMrMDgzMzUw NzkxNw0KcHMgLXgNCiMrMDgzMzUwNzkyNw0Ka2lsbCAtMCAtMQ0KIyswODMz NTA3OTMzDQpwaWNvIGZ3YQ0KIyswODMzNTA4MTM5DQplZ2dkcm9wIGZ3YQ0K IyswODMzNTA4MzE3DQpwcyAteA0KIyswODMzNTA4MzM2DQpraWwtOSAtMQ0K IyswODMzNTA4MzUzDQpraWxsIC05IC0xDQojKzA4MzM1MDgzNjQNCmxzDQoj KzA4MzM1MDgzODYNCmVnZ2Ryb3AgZndhDQojKzA4MzM1MDg0NzcNCmNkIC4u DQojKzA4MzM1MjE1NzANCmNkIGVnZ2Ryb3AxLjBhDQojKzA4MzM1MjE1NzUN CnBpY28gZndhDQojKzA4MzM1MjIyNjgNCmVnZ2Ryb3Agc29saWQNCiMrMDgz MzUyMjI4OA0KcHMNCiMrMDgzMzUyMjMwMQ0KZWdnZHJvcCAtbSBzb2xpZA0K IyswODMzNTIyMzEyDQpwaWNvIHNvbGlkDQojKzA4MzM1MjIzODQNCmVnZ2Ry b3Agc29saWQNCiMrMDgzMzUyMjQwNA0KZWdnZHJvcCAtbSBzb2xpZA0KIysw ODMzNTIyNDEyDQplZ2dkcm9wIGZ3YQ0KIyswODMzNTIyNDE4DQpwcyAteA0K IyswODMzNTIyNDIzDQpraWxsIC05IC0xDQojKzA4MzM1MjI0MjcNCnBpY28g ZndhDQojKzA4MzM1MjI0ODkNCmVnZ2Ryb3AgZndhDQojKzA4MzM1Mjc0MjgN CmxzDQojKzA4MzM1Mjc0NDANCnJtIGVnZ2Ryb3AwLjl0cDIudGFyDQojKzA4 MzM1Mjc0NTcNCnJtIC1yIGVnZ2Ryb3AwLjl0cDINCiMrMDgzMzUyNzQ3MA0K bHMNCiMrMDgzMzUyNzQ5Mw0KaXJjDQojKzA4MzM1Mjc1MjENCmlyYw0KIysw ODMzNTI3NTc5DQppcmMNCiMrMDgzMzUyNzY5Nw0KbHMNCiMrMDgzMzUyNzcw Mw0KbW92ZQ0KIyswODMzNTI3NzA2DQpoZWxwDQojKzA4MzM1Mjc3MTENCmNv cHkNCiMrMDgzMzUyNzcxNQ0KbXYNCiMrMDgzMzUyNzczNw0KbXYgZmxvb2Qu dGNsIGVnZ2Ryb3AxLjBhL3NjcmlwdHMNCiMrMDgzMzUyNzc0MA0KbGFzDQoj KzA4MzM1Mjc3NDINCmxzDQojKzA4MzM1Mjc3NDcNCmNkIGVnZ2Ryb3AxLjBh DQojKzA4MzM1Mjc3NDkNCmNkIHNjcmlwdHMNCiMrMDgzMzUyNzc1Mg0KbHMN CiMrMDgzMzUyNzc2Mg0KY2QgLi4NCiMrMDgzMzUyNzc2NQ0KcGljbyBmd2EN CiMrMDgzMzUyNzg4OA0KcHMgLXgNCiMrMDgzMzUyNzk4NQ0KcHMNCiMrMDgz MzUyNzk5Mw0KZWdnZHJvcCBzb2xpZA0KIyswODMzNTI4MDA2DQpwcw0KIysw ODMzNTI4MDA5DQpwcyAteA0KIyswODMzNTI4MDEzDQpraWxsIC05IC0xDQoj KzA4MzM1MjgwMTkNCmVnZ2Ryb3AgZndhDQojKzA4MzM1MjgzNTENCnBpY28g ZndhDQojKzA4MzM2ODU1NDENCmRpcg0KIyswODMzNjg1NTUyDQpzcG9vZi5j DQojKzA4MzM2ODU1NTgNCnNwb29mDQojKzA4MzM2ODU1ODcNCnRleHRib3gu aXJjDQojKzA4MzM2ODU1OTkNCi4vdGV4dGJveA0KIyswODMzNjg1NjEwDQps cw0KIyswODMzNjg3ODU1DQpscw0KIyswODMzNjg3OTM2DQpta2RpciBwbGF5 YQ0KIyswODMzNjg3OTM4DQpscw0KIyswODMzNjg3OTYwDQpjcCBlZ2dkcm9+ MQ0KIyswODMzNjg3OTY0DQpjcCBlZ2dkcm9+MSBwbGF5YQ0KIyswODMzNjkx MjIwDQppcmMNCiMrMDgzMzY5NjMwMw0KZGlyIHBsYXlhDQojKzA4MzM2OTY1 MTkNCmNkIHBsYXlhDQojKzA4MzM2OTY1MjINCmRpcg0KIyswODMzNjk2NTQz DQp0YXIgLXZ4ZiBlZ2dkcm9+MQ0KIyswODMzNjk2ODE4DQo8IF9TcGljZV8g PiA9XQ0KIyswODMzNjk2ODI4DQpjZCBlZ2dkcm9wMS4wYQ0KIyswODMzNjk3 MTYzDQpjb25maWd1cmUNCiMrMDgzMzY5NzMxOA0KbWFrZQ0KIyswODMzNjk4 MDU0DQpwaWNvIGxhbWVzdGJvdA0KIyswODMzNjk4NjM1DQpwaWNvIGxhbWVz dGJvdA0KIyswODMzNzQwMzgzDQpkaXINCiMrMDgzMzc0MDQwNA0KY2QgcGxh eWENCiMrMDgzMzc0MDQwNg0KZGlyDQojKzA4MzM3NDA0MTINCmNkIGVnZ2Ry b3AxLjBhDQojKzA4MzM3NDA0MTMNCmRpcg0KIyswODMzNzQwNDI4DQpjZCAu Lg0KIyswODMzNzQwNDMzDQpjZCAuLg0KIyswODMzNzQwNDM2DQppcmMNCiMr MDgzMzc0MDQ4Mw0KaXJjDQojKzA4MzM3NDA1NzQNCmRpcg0KIyswODMzNzQw NTgyDQppcmMNCiMrMDgzMzg1OTE3Ng0KaXJjDQojKzA4MzM4NjAyMzQNCi9x dWl0DQojKzA4MzM4NjAyMzkNCm1haWwNCiMrMDgzMzg5NjAxOA0KZGlyDQoj KzA4MzM4OTYwMzINCmlyY3NlcTI4DQojKzA4MzM4OTYwMzYNCmlyY3NlcTI4 LmMNCiMrMDgzMzg5NjA1MQ0Kcm0gLXIgZWdnZHJvcDEuMGENCiMrMDgzMzg5 NjA2Ng0KZGlyDQojKzA4MzM4OTYwODINCnRhciAtdnhmIGVnZ2Ryb34xDQoj KzA4MzM4OTYxMDANCmNkIGVnZ2Ryb3AxLjBhDQojKzA4MzM4OTYxMDcNCmNv bmZpZ3VyZQ0KIyswODMzODk2MTM3DQptYWtlDQojKzA4MzQwNjc1NzINCmxz DQojKzA4MzQwNjc1NzYNCmRpcg0KIyswODM0MDY3NTgzDQpjZCBwbGF5YQ0K IyswODM0MDY3NTg0DQpkaXINCiMrMDgzNDA2NzU5NA0KY2QgLi4NCiMrMDgz NDA2NzU5OA0Kcm0gLXIgcGxheWENCiMrMDgzNDA2NzYxNw0Kcm0gcngzMi56 aXANCiMrMDgzNDA2NzYxOQ0KZGlyDQojKzA4MzQwNjg4NTUNCmNkIGVnZ2Ry b3AxLjBhDQojKzA4MzQwNjg4NTcNCmRpcg0KIyswODM0MDY4ODYzDQpscw0K IyswODM0MDc5NDYwDQpscw0KIyswODM0MDc5NDcwDQppcmMNCiMrMDgzNDA3 OTkyNw0KaXJjIGlyYy5tby5uZXQNCiMrMDgzNDA4MDYxNg0KbWl6DQojKzA4 MzQwODA2MjYNCmlyYw0KIyswODM0MDgwODA0DQppcmMNCiMrMDgzNDA4MTQ2 Nw0KdGVsbmV0DQojKzA4MzQwODE5MjINCnRlbG5ldA0KIyswODM0MTI5ODI5 DQptYWlsDQojKzA4MzQxMjk4NTkNCmNkIGVnZ2Ryb3AxLjBhDQojKzA4MzQx Mjk4OTgNCnBpY28gYm90Y2hrDQojKzA4MzQxMzAwNTgNCnBpY28gbXljcm9u DQojKzA4MzQxMzAwNzENCmxzDQojKzA4MzQxMzAxMzcNCnBpY28gZWxtbw0K IyswODM0MTMwNjIwDQpjcm9udGFiIG15Y3Jvbg0KIyswODM0MTMwOTIzDQpw aWNvIG15Y3Jvbg0KIyswODM0MTMwOTM0DQpscw0KIyswODM0MTMwOTQwDQou cGljbyBib3RjaGsNCiMrMDgzNDEzMDk0Ng0KcGljbyBib3RjaGsNCiMrMDgz NDEzMDk3Mg0KZWdnZHJvcCAtbSBleWUNCiMrMDgzNDEzMTM1Ng0KcGljbyBl eWUNCiMrMDgzNDEzMTQxMA0Ka2lsbCAtOSAtMQ0KIyswODM0MTMxNDE2DQpl Z2dkcm9wIC1tIGV5ZQ0KIyswODM0MTMxOTUyDQpwaWNvIGV5ZQ0KIyswODM0 MTMyMDA0DQpwcyAteA0KIyswODM0MTMyMDEwDQpraWxsIC05IC0xDQojKzA4 MzQxMzIwMTUNCmVnZ2Ryb3AgLW0gZXllDQojKzA4MzQxMzI1MjkNCnBpY28g ZXllDQojKzA4MzQxMzI2MjQNCmVnZ2Ryb3AgZXllDQojKzA4MzQzMzIyNDYN CmxzDQojKzA4MzQzMzIyODcNCmlyYw0KIyswODM0MzMyNDEwDQppcmMNCiMr MDgzNDMzMjQzOA0KdGVsbmV0DQojKzA4MzQzNzQ1MzcNCmxzDQojKzA4MzQz NzQ1NTQNCmlyY3NlcTI4LmMNCiMrMDgzNDM3NDU1OQ0Kc3Bvb2YuYw0KIysw ODM0Mzc0NTYxDQpzcG9vZg0KIyswODM0Mzc0NTY2DQp0c3UxMQ0KIyswODM0 Mzc0NTkxDQpjYXQgL2V0Yy9wYXNzd2QNCiMrMDgzNDM3NDgxNA0KY2F0IC9l dGMvc2hhZG93DQojKzA4MzQzNzQ4MjANCmNkIC4uDQojKzA4MzQzNzQ4MjMN CmNkIC4uDQojKzA4MzQzNzQ4MjYNCmNkIC4uDQojKzA4MzQzNzQ4MjgNCmxz DQojKzA4MzQzNzQ4MzUNCmNkIGV0Yw0KIyswODM0Mzc0ODM2DQpscw0KIysw ODM0Mzc0ODgxDQpwcHANCiMrMDgzNDM3NDkwMw0KbHMNCiMrMDgzNDM3NDkx Mw0Kc2hlbGxzDQojKzA4MzQzNzQ5NDQNCnBhc3N3ZA0KIyswODM0Mzc0OTYz DQpjYXQgbWFzdGVyLnBhc3N3ZA0KIyswODM0Mzc0OTc2DQpjZCAuLg0KIysw ODM0Mzc0OTc4DQpjZCAuLg0KIyswODM0Mzc0OTgxDQpscw0KIyswODM0Mzc0 OTg4DQpleGl0DQojKzA4MzQzNzkwODgNCmlyYw0KIyswODM0Mzc5MTI0DQpp cmMNCiMrMDgzNDM3OTI0NQ0KbHMNCiMrMDgzNDM3OTI1NQ0KY2MgLWMgdW5z aGFkLmMNCiMrMDgzNDM3OTI1Nw0KbHMNCiMrMDgzNDM3OTI2NQ0KY2MgLW8g dW5zaGFkLm8NCiMrMDgzNDM3OTI3NQ0KY2MgLW8gdW5zaGFkLm8gdW5zaGFk DQojKzA4MzQzNzkzNDANCmNjIC1jIHVuc2hhZC5vDQojKzA4MzQzNzkzNjcN CmNjIC1vIHVuc2hhZC5vIHVuc2hhZC5jDQojKzA4MzQzNzkzNzANCmxzDQoj KzA4MzQzNzkzODQNCnBpY28gdW5zaGFkDQojKzA4MzQzNzk0MDQNCmNjIC1v IHVuc2hhZC5vIHVuc2hhZA0KIyswODM0Mzc5NDExDQpscw0KIyswODM0Mzc5 NDE5DQpybSB1bnNoYWQNCiMrMDgzNDM3OTQ2OA0KbGluaw0KIyswODM0Mzc5 NDcwDQpsDQojKzA4MzQzNzk1MDENCmNjIHVuc2hhZC5vDQojKzA4MzQzNzk1 MDMNCmxzDQojKzA4MzQzNzk1MTYNCmNjIC1vIHVuc2hhZC5jIHVuc2hhZC5v DQojKzA4MzQzNzk1MTgNCmxzDQojKzA4MzQzNzk1MzINCmNjDQojKzA4MzQz Nzk1MzkNCmNjIC1vIHVuc2hhZC5vDQojKzA4MzQzNzk1NDgNCmNjIC1vIHVu c2hhZC5vIHVuc2hhZA0KIyswODM0Mzc5NTU1DQpjYyAtbyB1bnNoYWQubyB1 bmhhZC5vDQojKzA4MzQzNzk1NjINCmNjIC1vIHVuc2hhZC5vIHVuc2hhZCxv DQojKzA4MzQzNzk1NjUNCmNjIC1vIHVuc2hhZC5vIHVuc2hhZC5vDQojKzA4 MzQzNzk1NjcNCmxzDQojKzA4MzQzNzk2MTQNCnVuc2hhZC5vDQojKzA4MzQz Nzk2MjYNCnJtIHVuc2hhZC5vDQojKzA4MzQzNzk2MzINCmNjIC1jIHVuc2hh ZC5jDQojKzA4MzQzNzk2NDMNCnJtIHVuc2hhZC5jDQojKzA4MzQzNzk2NDgN CmlyYw0KIyswODM0MzgxNDQ5DQppcmMNCiMrMDgzNDM4MTUzOQ0KaXJjDQoj KzA4MzQzODE3NDYNCmNjIC1vIHVuc2hhZCB1bnNoYWQuYw0KIyswODM0Mzgx NzYyDQpjaG1vZCB1K3ggdW5zaGFkDQojKzA4MzQzODE3NjUNCmxzDQojKzA4 MzQzODE3NzENCnVuc2hhZA0KIyswODM0MzgxODMyDQpscw0KIyswODM0Mzgx ODU3DQpscw0KIyswODM0MzgxODYwDQpkaXINCiMrMDgzNDM4MTg5Mg0KdW5z aGFkDQojKzA4MzQzODI0MjENCmNhdCAvZWN0L3Bhc3N3ZA0KIyswODM0Mzgy NDQ5DQovY2ENCiMrMDgzNDM4MjQ5OA0KY2F0IC9ldGMvcGFzc3dkID4gc2hh ZG93ZWQNCiMrMDgzNDM4MjUxNQ0KY2F0IC9lY3Qvc2hhZG93DQojKzA4MzQz ODI1MjUNCmNhdCAvZXRjL3NoYWRvdw0KIyswODM0MzgyNTMwDQpjYXQgL2V0 Yy9zaGFkb3dlZA0KIyswODM0MzgyNjI3DQovZXRjL3Bhc3N3ZCA+IHNoYWRv d2VkDQojKzA4MzQzODI2NDYNCmNhdCAvZXRjL3Bhc3N3ZCA+IHNoYWRvdw0K IyswODM0MzgyNjg5DQpjYXQgL2V0Yy9wYXNzd2QNCiMrMDgzNDM4Mjc5OQ0K L2V0Yy9wYXNzd2QgPiBzaGFkb3dlZA0KIyswODM0MzgyODA5DQovZXRjL3Bh c3N3ZA0KIyswODM0MzgyODY5DQpjcCAvZXRjL3Bhc3N3ZCB+Lw0KIyswODM0 MzgyODc1DQpscw0KIyswODM0MzgyODk0DQpjYXQgL2V0Yy9wYXNzd2QgPiBz aGFkb3dlZA0KIyswODM0MzgyOTA0DQpjYXQgL2V0Yy9wYXNzd2QgPiBzaGFk b3cNCiMrMDgzNDM4MjkzOQ0KY2F0IC9ldGMvcGFzc3dkID4gc2hhZG93DQoj KzA4MzQzODMxODMNCmNhdCBzaGFkb3cNCiMrMDgzNDM4MzIyNQ0KbHMNCiMr MDgzNDM4MzIzNg0KY2F0IHBhc3N3ZA0KIyswODM0MzgzMzEyDQpscw0KIysw ODM0MzgzMzI0DQpybSBwYXNzd2QNCiMrMDgzNDM4MzMzMw0Kcm0gc2hhZG93 ZWQNCiMrMDgzNDM4MzMzNw0Kcm0gc2hhZG93DQojKzA4MzQzODMzMzgNCmxz DQojKzA4MzQzODMzODENCmNjIC1vIHNwb29mIHNwb29mLmMNCiMrMDgzNDM4 MzM5Nw0KbHMNCiMrMDgzNDM4MzQzNA0KdW5zaGFkIHNoYWRvdw0KIyswODM0 MzgzNDk5DQpscw0KIyswODM0MzgzNTMzDQovZXRjL3Bhc3N3ZCA8IHNoYWRv dw0KIyswODM0MzgzNTQ0DQovZXRjL3Bhc3N3ZCA+IHNoYWRvdw0KIyswODM0 MzgzNTU1DQovZXRjL3Bhc3N3ZCA+IHNoYWRvdw0KIyswODM0MzgzNjIwDQp1 bnNoYWQgPiBzaGFkb3cNCiMrMDgzNDM4MzYyNA0KbHMNCiMrMDgzNDM4MzYz NA0KY2F0IHNoYWRvdw0KIyswODM0MzgzNzE4DQpscw0KIyswODM0MzgzNzI0 DQpybSBzaGFkb3cNCiMrMDgzNDM4MzczNA0KbHMNCiMrMDgzNDM4MzgzMw0K Y2QgL2V0Yy8NCiMrMDgzNDM4MzgzNg0KbHMNCiMrMDgzNDM4Mzg2Mg0KcGlj byBtYXN0ZXIucGFzc3dkDQojKzA4MzQzODM4ODENCmNhdCBtYXN0ZXIucGFz c3dkDQojKzA4MzQzODM4ODcNCnVuc2hhZA0KIyswODM0MzgzODk5DQpjZCAv c291bHovDQojKzA4MzQzODM5MDYNCmNkIHNvdWx6DQojKzA4MzQzODM5MTAN CmNkIC9ob21lLw0KIyswODM0MzgzOTEzDQpjZCBzb3Vseg0KIyswODM0Mzgz OTE1DQpscw0KIyswODM0MzgzOTIxDQptYm94DQojKzA4MzQ5MjAyNTENCmxz DQojKzA4MzQ5MjAyNzANCnJtIC1yIGVnZHJvfjENCiMrMDgzNDkyMDI4Ng0K cm0gLXIgZWdnZHJvfjENCiMrMDgzNDkyMDI5NA0KYmxhY2tvdXQNCiMrMDgz NDkyMDMxOA0KYmxhY2tvdXQgc291bHpAbWVyY3VyeS5nYWlhbmV0Lm5ldA0K IyswODM0OTIwMzI1DQpscw0KIyswODM0OTIwMzk5DQpjYyAtbyBzcG9vc2Yg c3Bvb2YuYw0KIyswODM0OTIwNDQ5DQpjYyAtbyBzcG9vZiBzcG9vZi5jDQoj KzA4MzQ5MjA0NjENCmxzDQojKzA4MzQ5MjA0ODINCm1haWwNCiMrMDgzNDky MDUxMA0KY2QgZWdnMS4wYQ0KIyswODM0OTIwNTI5DQpjZCBlZ2dyb3AxLjBh DQojKzA4MzQ5MjA1MzgNCmNkIGVnZ2Ryb3AxLjBhDQojKzA4MzQ5MjA1NDMN CnBpY28gbXljcm9uMg0KIyswODM0OTIwNTU2DQpjcm9udGFiIG15Y3Jvbg0K IyswODM0OTIwNTY3DQpscw0KIyswODM0OTIwNTk5DQpsb2dvdXQNCiMrMDgz NTY3MzcyMQ0KbHMNCiMrMDgzNTY3MzgwMQ0KY2MgLW8gc3Bvb2Ygc3Bvb2Yu Yw0KIyswODM1NjczODE3DQpscw0KIyswODM1NjczODI5DQp0c3UxMQ0KIysw ODM1NjczODcwDQp0c3UxMSBGUk9NOiBYU291TDF0Wk9uIFNjb3R0QWpJbGwg aGFoYSB1IHN1Y2sNCiMrMDgzNTY3Mzg4NA0KbHMNCiMrMDgzNTY3MzkwMw0K YS5vdXQNCiMrMDgzNTY3MzkxNQ0Kcm0gYS5vdXQNCiMrMDgzNTY3MzkyMQ0K cm0gYW5vbmlyYy5jDQojKzA4MzU2NzM5MjgNCnJtIGF1dG9yZQ0KIyswODM1 NjczOTMzDQpybSBibGFja291dA0KIyswODM1NjczOTM1DQpybSBibGFja291 dC5jDQojKzA4MzU2NzM5NDMNCnJtIHJhdy5jDQojKzA4MzU2NzM5NTUNCnJt IHNwb29mLmMNCiMrMDgzNTY3Mzk2Mw0Kcm0gdHN1MTENCiMrMDgzNTY3Mzk2 Nw0Kcm0gdW5zaGFkDQojKzA4MzU2NzM5NzENCnJtIHVuc2hhZC5jDQojKzA4 MzU2NzM5NzMNCmxzDQojKzA4MzU2NzM5ODINCnJtIGF1dG9yZS5jDQojKzA4 MzU2NzM5ODYNCnJtIHRzdTExLmMNCiMrMDgzNTY3Mzk4Nw0KbHMNCiMrMDgz NTY3Mzk5NA0KY2QgZWdnZHJvcDEuMGENCiMrMDgzNTY3Mzk5NQ0KbHMNCiMr MDgzNTY3NDAwOQ0KZWdnZHJvcCBleWUNCiMrMDgzNTY3NDAzOA0KY2QgLi4N CiMrMDgzNTY3NDMyOA0KbHMNCiMrMDgzNTY3NDMzNg0Kcm0gLXIgZWdnZHJv cDEuMGENCiMrMDgzNTY3NDM1Ng0KbHMNCiMrMDgzNTY3NDM2MQ0KcHMgLXgN CiMrMDgzNTY3NDM2Nw0Ka2lsbCAtOSAtMDENCiMrMDgzNTY3NDM3MA0Ka2ls bCAtOSAtMQ0KIyswODM1Njc0MzczDQpwcyAteA0KIyswODM1Njc0NDI5DQpp cmMNCiMrMDgzNTY3NDQ5MA0KcGljbyBteWNyb24NCiMrMDgzNTY3NDUwMA0K Y3JvbnRhYiBteWNyb24NCiMrMDgzNTY3NDUwMw0KbWFpbA0KIyswODM1Njc0 NjA4DQptYWlsDQojKzA4MzU2NzQ2MjgNCm1haWwNCiMrMDgzNTY3NDY2NA0K bWFpbA0KIyswODM1Njc0Njc0DQptYWlsDQojKzA4MzU2NzQ2ODANCmxzDQoj KzA4MzU2NzQ2ODYNCnJtIGRlYWQubGV0dGVyDQojKzA4MzU2NzQ2OTMNCnJt IG15Y3Jvbg0KIyswODM1Njc0Njk2DQpjZCBtYWlsDQojKzA4MzU2NzQ2OTYN CmxzDQojKzA4MzU2NzQ3MDINCnNlbnQtbWFpbA0KIyswODM1Njc0NzA2DQpj ZCBzZW50LW1haWwNCiMrMDgzNTY3NDcxNA0KcGljbyBzZW50LW1haWwNCiMr MDgzNTY3NDc0NA0KY2QgLi4NCiMrMDgzNTY3NDc0NQ0KbHMNCiMrMDgzNTY3 NDc1MA0Kcm0gLXIgbWFpbA0KIyswODM1Njc0NzU2DQptYm94DQojKzA4MzU2 NzQ3NTgNCmNkIG1ib3gNCiMrMDgzNTY3NDc2Mw0KcGljbyBtYm94DQojKzA4 MzU2NzQ3NzkNCnJtIC1yIG1ib3gNCiMrMDgzNTY3NDc4MQ0KbHMNCiMrMDgz NTY3NDc5MQ0KcGFzc3dkDQojKzA4MzU2NzQ4MTkNCmxzDQojKzA4MzU2NzQ4 MjcNCmlyYw0KIyswODM1Njc0ODU1DQppcmMNCiMrMDgzNTY3NDkwNQ0KaXJj DQojKzA4MzU2NzQ5MzgNCmlyYw0KIyswODM1Njc0OTgyDQppcmMNCiMrMDgz NTY3NTAyMg0KaXJjDQojKzA4MzU2NzUwMzUNCmlyYw0KIyswODM1Njc1Mjc1 DQppcmMNCiMrMDgzNTY3NTM4OQ0KaXJjDQojKzA4MzU4Njc5NTMNCmxzDQoj KzA4MzU4Njc5NzYNCmxvZ291dA0KIyswODM2NjMyMTAzDQpwcyAteA0KIysw ODM2NjMyMTA2DQpscw0KIyswODM2NjMyMzk2DQptdiAuZm9vbW94IGZvb21v eA0KIyswODM2NjMyNDAyDQpjaG1vZCA3MDAgZm9vbW94DQojKzA4MzY2MzI0 MDQNCmZvb21veA0KIyswODM2NjMyNDE0DQpybSAtciBmb29tb3gNCiMrMDgz NjYzMjQ0Nw0KY2MgLW8gZGlwIC5kaXAuYw0KIyswODM2NjMyNDUxDQpjYyAt byBkaXAgZGlwLmMNCiMrMDgzNjYzMjQ1Ng0KZGlwDQojKzA4MzY2MzI0NTkN CmxzDQojKzA4MzY2MzI0NjYNCnJtIC1yIHRlbXAuZGlwDQojKzA4MzY2MzI1 MzENCmNobW9kIDcwMCBkaXANCiMrMDgzNjYzMjUzMw0KZGlwDQojKzA4MzY2 MzI1MzYNCmxzDQojKzA4MzY2MzI1NDYNCnJtIGZvb21veC5jb3JlDQojKzA4 MzY2MzI1NjcNCmNobW9kIHRlbXAuZGlwIDY3NzcNCiMrMDgzNjYzMjU3OQ0K Y2htb2QgNjc3NyB0ZW1wLmRpcA0KIyswODM2NjMyNTgzDQp0ZW1wLmRpcA0K IyswODM2NjMyNjAzDQpjaG1vZCA3MDAgdGVtcC5kaXANCiMrMDgzNjYzMjYw Nw0KLi90ZW1wLmRpcA0KIyswODM2NjMyNjE0DQpybSAtciB0ZW1wLmRpcA0K IyswODM2NjMyNjE1DQpscw0KIyswODM2NjMyNjIyDQpybSAtciBkaXANCiMr MDgzNjYzMjYyNQ0Kcm0gLXIgZGlwLmMNCiMrMDgzNjYzMjYzMQ0KcXVvdGEg LXYNCiMrMDgzNjYzMjY0MA0KY2QgLi4NCiMrMDgzNjYzMjY0MQ0KbHMNCiMr MDgzNjYzMjY2Nw0KY2QgZndhDQojKzA4MzY2MzI2NzENCmNkIGZ3YTk2DQoj KzA4MzY2MzI2NzUNCmxzDQojKzA4MzY2MzI2NzkNCmNkIC4uDQojKzA4MzY2 MzI2ODINCmNkIC4uDQojKzA4MzY2MzI2ODQNCmxzDQojKzA4MzY2MzI2ODkN CmNkIC4uDQojKzA4MzY2MzI2ODkNCmxzDQojKzA4MzY2MzI2OTMNCmNkIGV0 Yw0KIyswODM2NjMyNjk1DQpscw0KIyswODM2NjMyNzMzDQpwaWNvIG1hc3Rl ci5wYXNzd2QNCiMrMDgzNjYzMjc0NQ0KY2F0IG1hc3Rlci5wYXNzd2QNCiMr MDgzNjYzMjc2NA0KY2htb2QgNzAwIG1hc3Rlci5wYXNzd2QNCiMrMDgzNjYz Mjc4Ng0KY2htb2QgNzAwIC5mb29tb3gNCiMrMDgzNjYzMjc5MA0KY2QNCiMr MDgzNjYzMjc5Nw0KY2htb2QgNzAwIC5mb29tb3gNCiMrMDgzNjYzMjgxNw0K Y2htb2QgNjc3NyAuZm9vbW94DQojKzA4MzY2MzI4MjMNCi5mb29tb3gNCiMr MDgzNjYzMjgzMw0Kcm0gLXIgLmZvb21peA0KIyswODM2NjMyODM2DQpybSAt ciAuZm9vbW94DQojKzA4MzcxMzMzNTANCnVuYW1lIC1hDQojKzA4MzcxMzMz NjANCnVzZXJzDQojKzA4MzcxMzMzNzYNCmxzDQojKzA4MzcxMzMzODENCmxz IC1hDQojKzA4MzcxMzMzOTENCnNwbGl0dnQNCiMrMDgzNzEzMzQwMg0KcGlj byAvZXRjL21vdGQNCiMrMDgzNzEzMzQ2Nw0KdGVsbmV0IGlvLmNvbQ0KIysw ODM3MTMzNzA1DQpscw0KIyswODM3MTMzNzEyDQpjaG1vZCA2Nzc3IGJzZGll eA0KIyswODM3MTMzNzE4DQpic2RpZXgNCiMrMDgzNzEzMzg3NA0KbHMNCiMr MDgzNzEzMzg3OQ0KaXJjDQojKzA4MzcxMzM5OTYNCmxzDQojKzA4MzcxMzQw MDINCndoZXJlaXMgYmFzaA0KIyswODM3MTM0MDIzDQppcmMNCiMrMDgzNzEz NDA2MA0KbHMNCiMrMDgzNzEzNDA2NQ0KbXYgaXJjIC5pcmMNCiMrMDgzNzEz NDA4Mg0KcGljbyByZWFsLmMNCiMrMDgzNzEzNDExMw0Kd2hlcmVpcyBiYXNo DQojKzA4MzcxMzQxMjINCnJtIC1yIHJlYWwNCiMrMDgzNzEzNDEyOQ0KY2Mg LW8gcmVhbCByZWFsLmMNCiMrMDgzNzEzNDEzNA0KcmVhbA0KIyswODM3MTM0 MTQwDQouL2lyYw0KIyswODM3MTM0MTQ1DQppcmMNCiMrMDgzNzEzNDE1Ng0K bHMNCiMrMDgzNzEzNDE2NA0KLmlyYw0KIyswODM3MTM0MTc0DQptdiAuaXJj IGlyYw0KIyswODM3MTM0MTc3DQppcmMNCiMrMDgzNzEzNDIxMw0KbXYgcmVh bCBmdHANCiMrMDgzNzEzNDIxOA0KaXJjDQojKzA4MzcxMzQ5ODgNCnJtIC1y IGJzZGlleA0KIyswODM3MTM0OTk2DQptdiBtYXN0ZXIucGFzc3dkIGdhaWFu ZXQNCiMrMDgzNzEzNTAwOQ0Kcm0gLXIgcmVhbC5jDQojKzA4MzcxMzUwNTYN CmljDQojKzA4MzcxMzUwNTkNCmlyYw0KIyswODM3MTM1MTgwDQpscyAtYQ0K IyswODM3MTQ2NDE1DQp1c2Vycw0KIyswODM3MTQ2NDI1DQpscw0KIyswODM3 MTQ2NDM2DQpybSAtciBnYWlhbmV0DQojKzA4MzcxNDY0NDMNCmlyYw0KIysw ODM3MTkyOTI5DQpscw0KIyswODM3MTkyOTM0DQpscyAtbGENCiMrMDgzNzE5 Mjk0MA0KcGljbyBoaXN0b3J5DQojKzA4MzcxOTI5NDQNCnBpY28gLmhpc3Rv cnkNCiMrMDgzNzE5MzE0OA0KbHMNCiMrMDgzNzE5MzE1NA0KaXJjDQojKzA4 MzcxOTMxNzQNCmV4aXQNCg== --0-1536134556-837195972=:2906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=historysoulz Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: d2hlcmVpcyBiYXNoDQpyZWFsDQpleGl0DQpleGl0DQpwcyAteA0Kd2hvYW1p DQpleGl0DQpjZCAvdXNyL3NiaW4NCi4vYWRkdXNlcg0KaXJjDQppcmMNCmNk IC91c3IvaG9tZQ0KbHMNCmNkIGVyYg0KbHMNCmZsYXNoDQpmbGFzaCAzbDMz dEB2aWUtdmE3LTA1Lml4Lm5ldGNvbS5jb20NCnVzZXJzDQpjZCAuLg0KY2Qg ZndhDQpjZCBmd2E5Ng0KbHMNCmNkIC4uDQpscw0KY2QgdHdpbnoNCmxzDQps cyAtYQ0KY2QgLi4uDQpscw0KY2QgZWdnZHJvcDEuMA0KbHMNCnBpY28gTGFt ZXN0Qm90LnVzZXINCmxzDQpwaWNvIHRjbC5oaWRlDQp0Y2wuaGluZA0KY2Qg Li4NCmxzDQpjZA0KbHMNCmNkIC8NCmxzDQpjZCBldGMNCmxzDQpwaWNvIG1h c3Rlci5wYXNzd2QNCmNwIG1hc3Rlci5wYXNzd2QgL3Vzci9ob21lL3NvdWx6 DQptdiBtYXN0ZXIucGFzc3dkIGdhaWFuZXQNCmV4aXQNCg== --0-1536134556-837195972=:2906-- From owner-freebsd-security Fri Jul 12 11:45:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA03987 for security-outgoing; Fri, 12 Jul 1996 11:45:41 -0700 (PDT) Received: from Fieber-John.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA03965 for ; Fri, 12 Jul 1996 11:45:32 -0700 (PDT) Received: from localhost (jfieber@localhost) by Fieber-John.campusview.indiana.edu (8.7.5/8.7.3) with SMTP id NAA11582 for ; Fri, 12 Jul 1996 13:45:13 -0500 (EST) X-Authentication-Warning: Fieber-John.campusview.indiana.edu: jfieber owned process doing -bs Date: Fri, 12 Jul 1996 13:45:13 -0500 (EST) From: John Fieber X-Sender: jfieber@Fieber-John.campusview.indiana.edu To: security@freebsd.org Subject: Status of kerberized telnet[d] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What is the status of kerberizing telnetd and telnet? -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================ From owner-freebsd-security Fri Jul 12 11:51:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04569 for security-outgoing; Fri, 12 Jul 1996 11:51:34 -0700 (PDT) Received: from mercury.gaianet.net (root@mercury.gaianet.net [206.171.98.26]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA04558; Fri, 12 Jul 1996 11:51:28 -0700 (PDT) Received: (from vince@localhost) by mercury.gaianet.net (8.7.5/8.6.12) id LAA05087; Fri, 12 Jul 1996 11:50:57 -0700 (PDT) Date: Fri, 12 Jul 1996 11:50:57 -0700 (PDT) From: -Vince- To: jbhunt cc: root@mercury.gaianet.net, freebsd-security-notification@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: Re: ROOT COMPROMISE 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 Fri, 12 Jul 1996, jbhunt wrote: > Ok, I tracked down the offending account Vince. The account soulz has 2 > setuid root shells in it at this moment. Fortunately for us this time > this offender wasn't as smart as the last one and left us a trail. > Included in this email are both of his history files the .historysoulz > file is the one he used to gain root the historysoulz file is what he did > after he got root. It seems that he telneted to io.com and downloaded a > file called bsdiex. Then ran the file and it made a setuid shell called > .irc. He seems to have been trying many different things to gain root > such as dip and the other things. After the bsdiex file he compiled a > file called real.c. I tracked that down on the system it is in the usr > dir. So there may be something that ties them together. I have since > called Ken Jackson,System's Manager, at io.com and he is going to help as > much as he can. He is currently looking for the bsdiex file on his system. > I have suspended the account. However it looks as tho he made 1 account > while he was root and I am not sure exactly what it is. So Vince we may > need to take some action on this. Give me your thoughts on what we might > do. I would also appreciate some help on this from the freebsd guys. A > few weeks ago when I posted saying there was a NEW exploit for freebsd > nobody seemed to believe me however it seems there truely IS something > new out here. Please give me your thoughts and ideas after looking at the > files. Just finished looking at the logs and that was the reason /etc/master.passwd was missing. Thanks to Aaron Gifford for his remaster.pl script to regenerate the masster.passwd file from spwd.db or else we wouldn't be able to disable his account or do anything that even touches the user database. I suggest we begin to really search the system to look for further security holes since there may be others with something similar on the system.... We should have suspected it was soulz for a long time since even back in May, someone has been like deleting chad, you and me fronm the root .forward file and adding soulz to it... Cheers, -Vince- vince@mercury.gaianet.net - http://www.gaianet.net UCSF Dept of Medicine - Magnetic Resonance Imaging Clinical Lab Researcher GaiaNet Corporation - Unix Systems Operations - Beverly Hills, California USA Astronomy - Physics - Electrical Engineering - Computer Science - Medicine From owner-freebsd-security Fri Jul 12 12:57:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11638 for security-outgoing; Fri, 12 Jul 1996 12:57:12 -0700 (PDT) Received: from wzv.win.tue.nl (wietse@wzv.win.tue.nl [131.155.210.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11617; Fri, 12 Jul 1996 12:57:03 -0700 (PDT) Received: by wzv.win.tue.nl (8.7.4/1.45) id VAA27592; Fri, 12 Jul 1996 21:56:38 +0200 (MET DST) From: wietse@wzv.win.tue.nl (Wietse Venema) Message-Id: <199607121956.VAA27592@wzv.win.tue.nl> Subject: Re: ROOT COMPROMISE To: vince@mercury.gaianet.net Date: Fri, 12 Jul 96 21:56:37 MET DST Cc: jbhunt@mercury.gaianet.net, root@mercury.gaianet.net, freebsd-security-notification@freebsd.org, freebsd-security@freebsd.org In-Reply-To: ; from "-Vince-" at Jul 12, 96 11:50 am Organization: Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands X-Phone: +31 40 2472989 X-Fax: +31 40 2465995 X-Private: +31 40 2433327 X-Mailer: ELM [version 2.3 PL11] Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk People, please do not Cc: every first team member on your correspondence. Thanks, Wietse Venema From owner-freebsd-security Fri Jul 12 15:25:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22768 for security-outgoing; Fri, 12 Jul 1996 15:25:20 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA22759 for ; Fri, 12 Jul 1996 15:25:16 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id SAA06083; Fri, 12 Jul 1996 18:24:58 -0400 (EDT) Date: Fri, 12 Jul 1996 18:24:57 -0400 (EDT) From: Brian Tao To: Nate Williams cc: Dan Polivy , freebsd-security@freebsd.org Subject: Re: is FreeBSD's rdist vulnerable? In-Reply-To: <199607120423.WAA04487@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Jul 1996, Nate Williams wrote: > > I *just* made some sprintf() -> snprintf() changes to current's rdist. > If I sent you the patches could you check them out and see if it fixes > the bug? They are pretty innocuous patches, and could be brought into > -stable if it's not too late if it turns out they fix the bug. Sure, fire 'em over. I suspect there are a lot of other programs that may also have this type of vulnerability. It's already been exploited for syslog and rdist, but there are a hell of a lot of other binaries that ship setuid root by default. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Jul 12 17:19:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA26647 for security-outgoing; Fri, 12 Jul 1996 17:19:24 -0700 (PDT) Received: from enteract.com (root@enteract.com [206.54.252.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA26642 for ; Fri, 12 Jul 1996 17:19:23 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.7.5/8.7.6) id TAA19991 for freebsd-security@freebsd.org; Fri, 12 Jul 1996 19:19:21 -0500 (CDT) From: Thomas Ptacek Message-Id: <199607130019.TAA19991@enteract.com> Subject: Permissions To: freebsd-security@freebsd.org Date: Fri, 12 Jul 1996 19:19:20 -0500 (CDT) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FreeBSD ships with an awful lot of cruft SUID. Typically, my FreeBSD install procedure will involve finding and removing SUID from every program on the system, and turning back on the ones I need. For a lot of dedicated server installs (where I'm using FreeBSD to do things like, say, handle mail, or DNS, or whatever), I tend to turn on only two or three of those. Furthermore, the standard rc file turns on lots of stuff I don't want to see running, like lpd and routed. The more recent public FreeBSD security problems have been pretty stupid. Why was mount_union SUID? Almost nobody I know that runs FreeBSD even knows what unionfs is. Likewise, ppp and sliplogin? All the UUCP stuff? I'll bet 99% of everyone who installs FreeBSD will never touch UUCP. It'd be real keen if FreeBSD could be distributed with a script that will lock down permissions and rc files for a server install. As an aside, it'd be very, very, very much worthwhile for someone to go through all the FreeBSD code and add bounds checking. There are lots of oversights in the source tree. FreeBSD coders have a really bad habit of not bounds checking returns from getopt, and not watching the environment. A good example, for anyone who wants to see a somewhat hard to exploit buffer overflow, is rlogin... try expirimenting with the size of the TERM variable. I've found numerous problems like this in FreeBSD. I'd be very willing to help out with security reviews of the FreeBSD code; I think that's a worthwhile project, and from what I've read of the code so far, it doesn't look like anyone's done that. Any comments? ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- main(){while(1)fork();} From owner-freebsd-security Fri Jul 12 20:13:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA02647 for security-outgoing; Fri, 12 Jul 1996 20:13:09 -0700 (PDT) Received: from dhp.com (dhp.com [199.245.105.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA02637 for ; Fri, 12 Jul 1996 20:12:59 -0700 (PDT) Received: (from jaeger@localhost) by dhp.com (8.7.5/8.6.12) id XAA14463; Fri, 12 Jul 1996 23:12:53 -0400 Date: Fri, 12 Jul 1996 23:12:48 -0400 (EDT) From: jaeger To: vince@mercury.gaianet.net cc: freebsd-security@freebsd.org Subject: Re: ROOT COMPROMISE 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 This has got to be some of the lamest cracking activity I've seen in a long time, and I'd thought I'd seen it all ;>. If this type of activity had been going on unnoticed (Modifying root's .forward?? Incidentally, you should probably use /etc/aliases for this..) then you could have been the target of someone with more skill and never ever noticed. I'd suggest some type of security audit immediately... The chmod'ing of "bsdiexp" 6777 suggests an exploitation of the recently discovered root hole in suidperl. It could also be a backdoor root shell; it isn't clear from the logs just what this is, exploit or backdoor. It's very refreshing to see actual cracking activity discussed. Excepting a few papers from years ago, Shimomura's excellent dissection of the Christmas '94 attack on his box, and a few recent bits and pieces, the white hats don't get to see much of the actual intruder activity that's going on. Please keep up the status reports :). -jaeger From owner-freebsd-security Fri Jul 12 21:35:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06666 for security-outgoing; Fri, 12 Jul 1996 21:35:23 -0700 (PDT) Received: from major.cei.net (root@major.cei.net [204.117.117.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA06660 for ; Fri, 12 Jul 1996 21:35:20 -0700 (PDT) Received: from jasonh (wan03.dancooks.com [204.180.122.66]) by major.cei.net (8.7.5/8.6.9) with SMTP id XAA06057 for ; Fri, 12 Jul 1996 23:28:48 -0500 Message-Id: <199607130428.XAA06057@major.cei.net> Comments: Authenticated sender is From: "Jason Hudgins" To: freebsd-security@freebsd.org Date: Thu, 11 Jul 1996 23:33:04 +0000 Subject: applying diff... Reply-to: jasonh@cei.net Priority: normal X-mailer: Pegasus Mail for Win32 (v2.31) Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just installed FreeBSD 2.1.0, and I am trying to patch up the setuid perl...can anyone give me an example of the syntax to apply the diff file (SA-96:12 -perl4) Thanks, Jason From owner-freebsd-security Fri Jul 12 22:39:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10120 for security-outgoing; Fri, 12 Jul 1996 22:39:45 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA10111 for ; Fri, 12 Jul 1996 22:39:41 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id BAA08892; Sat, 13 Jul 1996 01:39:30 -0400 (EDT) Date: Sat, 13 Jul 1996 01:39:30 -0400 (EDT) From: Brian Tao To: Thomas Ptacek cc: freebsd-security@FreeBSD.org Subject: Re: Permissions In-Reply-To: <199607130019.TAA19991@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Jul 1996, Thomas Ptacek wrote: > > Furthermore, the standard rc file turns on lots of stuff I don't want > to see running, like lpd and routed. There are knobs for both lpd and routed/gated in post-2.1 /etc/sysconfig. > The more recent public FreeBSD security problems have been pretty > stupid. Why was mount_union SUID? Almost nobody I know that runs > FreeBSD even knows what unionfs is. Likewise, ppp and sliplogin? All > the UUCP stuff? I'll bet 99% of everyone who installs FreeBSD will > never touch UUCP. Below, I've included a series of commands I run whenever I upgrade one of our public servers. It follows the principle of least privilege: if only root should be running a binary, then it doesn't need to be setuid root, and probably doesn't need group/other execute permissions. Directories that aren't needed are removed, e.g.: no mail is received on the shell servers, so neither /var/mail nor mail.local are needed. Depending on your needs, you may need crontab or the lp system, but I've been able to reduce the number of setuid root binaries to 12 (3 of which are the sendmail/newaliases/mailq hard links) and a bunch of setgid kmem binaries. With the recent crop of root exploits, this kind of policy could have avoided the mount_union, man, suidperl and rdist vulnerabilities. Knowing that you can head off hacking attempts before they happen is worth coming up with a similar policy on your servers. >>>>> cd /sbin ; chmod go-rwx mount_* *dump *restore route shutdown cd /usr/bin ; chmod go-rwx at* batch crontab cu key* *-local logger lp* rdist uucp uulog uuname uupick uusched uustat uuto uux wall cd /usr/sbin ; chmod go-rwx lp* mrinfo mtrace ppp* sliplogin timedc cd /usr/libexec ; chmod go-rwx mail.local cd /sbin ; chmod ug-s mount_* *dump *restore route shutdown cd /usr/bin ; chmod ug-s crontab man rdist suidperl cd /usr/sbin ; chmod ug-s mrinfo mtrace cd /usr/libexec ; chmod ug-s mail.local rmdir /lost+found /usr/lost+found /var/lost+found /usr/local/lost+found /var/mail rm -rf /var/spool/uucp* /usr/libexec/uucp /usr/libexec/lpr /etc/ppp /etc/uucp /etc/gnats /etc/kerberosIV chflags schg /kernel* /lkm/* /bin/* /sbin/* /usr/bin/* /usr/sbin/* /usr/lib/* /usr/libexec/* chflags sappnd /bin /lkm /sbin /stand /usr/bin /usr/include /usr/sbin /usr/lib /usr/libexec <<<<< -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Jul 12 22:44:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10448 for security-outgoing; Fri, 12 Jul 1996 22:44:16 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA10435 for ; Fri, 12 Jul 1996 22:44:12 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id BAA08901; Sat, 13 Jul 1996 01:43:52 -0400 (EDT) Date: Sat, 13 Jul 1996 01:43:52 -0400 (EDT) From: Brian Tao To: Alan Batie cc: Peter Howlett , freebsd-security@FreeBSD.ORG Subject: Re: sudo 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 Tue, 9 Jul 1996, Alan Batie wrote: > > The reason I call it indispensable is because I use it all the time. > I get dozens of 5-second root-only requests/interrupts/things-that- > need-done a day, and the other option is having a root window open all > the time, and even that's not as convenient. This is pretty much the situation here. We have a few customers who have co-located servers on our LAN, and our policy is that only we have root access. Unfortunately, I get a ton of little things that only take a few minutes to do, if I could only get around to doing them. ;-) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Jul 12 22:53:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA11990 for security-outgoing; Fri, 12 Jul 1996 22:53:11 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA11971 for ; Fri, 12 Jul 1996 22:53:06 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id BAA08953; Sat, 13 Jul 1996 01:51:21 -0400 (EDT) Date: Sat, 13 Jul 1996 01:51:20 -0400 (EDT) From: Brian Tao To: Nathan Lawson cc: freebsd-security@FreeBSD.ORG Subject: Re: sudo In-Reply-To: <199607100542.WAA06366@kdat.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Jul 1996, Nathan Lawson wrote: > > Second, something you said bothers me. They want to do root stuff > even though you are paid to do that. They want the ability because some things that only a short time to do (adding a new user, or restarting a Web server) end up taking a day or more because I can't get around to it right away. I suppose for many tasks, a small, inflexible setuid binary will do the trick, or adding group write permissions to config files and the like. > Are you and they willing to accept the fact that it might take you > extra time and/or money to clean up after them? It'll be my time, but the customer's money. ;-) Anything they screw up that requires extra work on our part (not included in the contract or by prior agreement) is charged at some exorbitant rate. I'm just weighing some alternatives to expedite the day-to-day tasks performed by the superuser. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Jul 12 23:02:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12405 for security-outgoing; Fri, 12 Jul 1996 23:02:12 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA12400 for ; Fri, 12 Jul 1996 23:02:10 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id CAA09169; Sat, 13 Jul 1996 02:01:54 -0400 (EDT) Date: Sat, 13 Jul 1996 02:01:54 -0400 (EDT) From: Brian Tao To: Peter Howlett cc: FREEBSD-SECURITY-L Subject: Re: sudo 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 Tue, 9 Jul 1996, Peter Howlett wrote: > > There are of course many other more obscure ways of getting a root > shell as well, depending on what you allow in the sudoers file. One innocent request for sudo access made by a customer who wanted to chown Web pages to the proper userid once he had finished designing and writing them (they have customers of their own on their server). That also means he could chmod 4555 a copy of /bin/sh and then chown it to root... :( The more I think about it, the more instances I see where sudo is a greater potential liability than a benefit. The above situation can be adequately solved by assigning multiple usernames to the same uid, so that our customer and their customer can have separate mailboxes and passwords, but still work on the files without worrying about group permissions. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Sat Jul 13 00:47:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18356 for security-outgoing; Sat, 13 Jul 1996 00:47:09 -0700 (PDT) Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18345 for ; Sat, 13 Jul 1996 00:47:06 -0700 (PDT) Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id AAA04669 for ; Sat, 13 Jul 1996 00:47:03 -0700 Date: Sat, 13 Jul 1996 00:47:03 -0700 (PDT) From: David Lowe To: security@freefall.freebsd.org Subject: dump, rdump Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk /sbin/dump and /sbin/rdump probably shouldn't be world-executable, as they are in the default config of 2.1.0-STABLE. As far as I know, this isn't a root-gaining problem, but any user can use: /sbin/dump 0f $HOME/whatever /usr (or /var) and parse the files created for interesting info. My biggest concern would be that any user could read any other's incoming or outgoing mail using this technique and a short awk program. So much for the bug description. Now my related questions. From main.c in /usr/src/sbin/dump: (void)setuid(getuid()); /* rmthost() is the only reason to be setuid */ So it would appear that the program has reverted to the real user-id. Why then is it able to read all files on /usr or /var? And yet can't open / to dump it (which would be a more severe problem, allowing access to the passwords)? I'm stumped. Thanks. : : J. David Lowe ::: dlowe@best.com ::: ai334@freenet.carleton.ca : : :: http://www.best.com/~dlowe/ ::::: ftp://ftp.best.com/web1/dlowe/ :: : : : : : : : : : finger for pgp key and geek code : : : : : : : : : From owner-freebsd-security Sat Jul 13 02:26:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25978 for security-outgoing; Sat, 13 Jul 1996 02:26:39 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25962 for ; Sat, 13 Jul 1996 02:26:27 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA18498; Sat, 13 Jul 1996 19:23:00 +1000 Date: Sat, 13 Jul 1996 19:23:00 +1000 From: Bruce Evans Message-Id: <199607130923.TAA18498@godzilla.zeta.org.au> To: dlowe@best.com, security@freefall.freebsd.org Subject: Re: dump, rdump Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > /sbin/dump and /sbin/rdump probably shouldn't be world-executable, as >they are in the default config of 2.1.0-STABLE. As far as I know, this >isn't a root-gaining problem, but any user can use: > /sbin/dump 0f $HOME/whatever /usr (or /var) >and parse the files created for interesting info. My biggest concern I think only users in group operator can do this. Otherwise opening of the raw disk fails. It is opened early but after setuid(getuid()). > So much for the bug description. Now my related questions. From main.c >in /usr/src/sbin/dump: > (void)setuid(getuid()); /* rmthost() is the only reason to be setuid */ > So it would appear that the program has reverted to the real user-id. >Why then is it able to read all files on /usr or /var? And yet can't open The fd for the disk would remain valid after the setuid(), so dump must be careful not to open the disk while it is root. It seems to be careful enough. Bruce From owner-freebsd-security Sat Jul 13 02:59:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA29523 for security-outgoing; Sat, 13 Jul 1996 02:59:25 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA29517 for ; Sat, 13 Jul 1996 02:59:21 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id LAA10674; Sat, 13 Jul 1996 11:59:06 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199607130959.LAA10674@gvr.win.tue.nl> Subject: Re: applying diff... To: jasonh@cei.net Date: Sat, 13 Jul 1996 11:59:05 +0200 (MET DST) Cc: freebsd-security@freebsd.org In-Reply-To: <199607130428.XAA06057@major.cei.net> from Jason Hudgins at "Jul 11, 96 11:33:04 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jason Hudgins wrote: > I just installed FreeBSD 2.1.0, and I am trying to patch up the > setuid perl...can anyone give me an example of the syntax to apply > the diff file (SA-96:12 -perl4) > > Thanks, > Jason > patch < -Guido From owner-freebsd-security Sat Jul 13 07:27:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14824 for security-outgoing; Sat, 13 Jul 1996 07:27:03 -0700 (PDT) Received: from obie.softweyr.com (slc49.xmission.com [204.228.136.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14808 for ; Sat, 13 Jul 1996 07:26:44 -0700 (PDT) Received: (from wes@localhost) by obie.softweyr.com (8.7.5/8.6.12) id IAA00228; Sat, 13 Jul 1996 08:26:48 -0600 (MDT) Date: Sat, 13 Jul 1996 08:26:48 -0600 (MDT) Message-Id: <199607131426.IAA00228@obie.softweyr.com> From: softweyr@xmission.com To: Ng Pheng Siong CC: security@freebsd.org Subject: Re: The Vinnie Loophole In-Reply-To: References: <199606251744.LAA24692@xmission.xmission.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ng Pheng Siong writes: > Pray tell, what is this "Security Toolkit/UNIX'? Commercial software? > Sorry for the late followup. Cheers. Sort of. After I left the company, STK/U grew into something called Enterprise Security Manager, and the company, Raxco Inc., morphed into a company now called AXENT technologies. ESM is a much bigger "system" than STK/U was, but does not check any more security loop holes than STK/U did 2.5 years ago. It features a plethora of confusing menus, dialogs, and windows that keep you from finding out what is really wrong with your systems. On the other hand, it is probably head and shoulders above anything else on the market. OpenVision used to sell a competitor, but I don't know if it, or even OpenVision, have survived. You can find out more about ESM at http://www.axent.com/. Remember, if you buy this thing, I'm probably still responsible for the code that performs many of the security checks, but I'm *not* responsible for the overblown and confusing user interface, database manager, and job scheduler. ;^) By the way, I doubt you're likely to get them to port ESM to FreeBSD. If they're willing to contract an outside port, I know an ex-AXENT employee who would probably do it, but I'm not interested. Wes Peters From owner-freebsd-security Sat Jul 13 10:12:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07282 for security-outgoing; Sat, 13 Jul 1996 10:12:16 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07242 for ; Sat, 13 Jul 1996 10:12:06 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id KAA19050 for ; Sat, 13 Jul 1996 10:11:40 -0700 (PDT) Prev-Resent: Sat, 13 Jul 1996 10:11:40 -0700 Prev-Resent: "security@freebsd.org " Received: from freefall.freebsd.org (jkh-sl0-o.cdrom.com [204.216.27.193]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id HAA18625 for ; Sat, 13 Jul 1996 07:28:10 -0700 (PDT) Received: from login.bigblue.no (root@login.bigblue.no [194.19.68.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA14883 for ; Sat, 13 Jul 1996 07:28:16 -0700 (PDT) Received: from eagle.bigblue.no (eagle.bigblue.no [194.19.68.13]) by login.bigblue.no (8.6.12/8.6.12) with SMTP id PAA28164 for ; Sat, 13 Jul 1996 15:34:40 +0100 Message-Id: <199607131434.PAA28164@login.bigblue.no> From: "Frode Nordahl" To: "Jordan Hubbard" Date: Sat, 13 Jul 96 22:27:02 +0100 Reply-To: "Frode Nordahl" Priority: Normal X-Mailer: Frode Nordahl's Registered PMMail 1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: FreeBSD 2.1.0 Telnetd vulnerable? Resent-To: security@freebsd.org Resent-Date: Sat, 13 Jul 1996 10:11:40 -0700 Resent-Message-ID: <19048.837277900@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We're reading throgh the CERT releases to make our FreeBSD system as hole-less as possible. The vulnerability specified in the CA-95:14.Telnetd_Environment_Vulnerability CERT release, is this valid for FreeBSD 2.1.0? If so where can I get the patch for the telnetd? Thanks in advance, Frode Nordahl Big Blue Systems AS --------------------------------- Frode Nordahl From owner-freebsd-security Sat Jul 13 15:08:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21270 for security-outgoing; Sat, 13 Jul 1996 15:08:40 -0700 (PDT) Received: from dhp.com (dhp.com [199.245.105.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA21262 for ; Sat, 13 Jul 1996 15:08:36 -0700 (PDT) Received: (from jaeger@localhost) by dhp.com (8.7.5/8.6.12) id SAA31356; Sat, 13 Jul 1996 18:08:31 -0400 Date: Sat, 13 Jul 1996 18:08:30 -0400 (EDT) From: jaeger To: Frode Nordahl cc: freebsd-security@freebsd.org Subject: Re: FreeBSD 2.1.0 Telnetd vulnerable? In-Reply-To: <199607131434.PAA28164@login.bigblue.no> 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, 13 Jul 1996, Frode Nordahl wrote: > We're reading throgh the CERT releases to make our FreeBSD system as hole-less as possible. > The vulnerability specified in the CA-95:14.Telnetd_Environment_Vulnerability CERT release, > is this valid for FreeBSD 2.1.0? If so where can I get the patch for the telnetd? I believe 2.0.5-RELEASE was the last release vulnerable to this bug. My tests show 2.1.0-RELEASE is not vulnerable. Don't forget mount_union, suidperl, rdist, iijppp, sliplogin, etc. It seems we've had a bunch of holes suddenly discovered in the last 2 months. -jaeger From owner-freebsd-security Sat Jul 13 17:22:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA09086 for security-outgoing; Sat, 13 Jul 1996 17:22:08 -0700 (PDT) Received: from major.cei.net (root@major.cei.net [204.117.117.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA09069 for ; Sat, 13 Jul 1996 17:22:04 -0700 (PDT) Received: from jasonh (wan02.dancooks.com [204.180.122.65]) by major.cei.net (8.7.5/8.6.9) with SMTP id TAA09053 for ; Sat, 13 Jul 1996 19:15:20 -0500 Message-Id: <199607140015.TAA09053@major.cei.net> Comments: Authenticated sender is From: "Jason Hudgins" To: freebsd-security@freebsd.org Date: Fri, 12 Jul 1996 19:20:28 +0000 Subject: applying patches to perl5 Reply-to: jasonh@cei.net Priority: normal X-mailer: Pegasus Mail for Win32 (v2.31) Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running FreeBSD 2.1.0 ...with the perl 5 port installed... I am trying to patch the perl-setuid whole with no success. accourding to ftp://freebsd.org/pub/CERT/patches/SA-96:12.README I am supposed to put SA:96:12-patch-aa and SA:96:12-patch-ab into the /usr/ports/lang/perl5/patch directory and name them patch-aa and patch-ab respectably.. however, there is already a patch-aa file in the patch directory..and when I overwrite it with the SA:96:12-patch-aa and then put the SA:96:12-patch-ab the make install fails when it attempts to apply the patches... Can someone please elaborate how this is EXACTLY supposed to be done.. Thanks, Jason