From owner-freebsd-security Sun Dec 22 05:54:55 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA03078 for security-outgoing; Sun, 22 Dec 1996 05:54:55 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA03065; Sun, 22 Dec 1996 05:54:43 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199612221354.FAA03065@freefall.freebsd.org> Subject: Re: (fwd) FYI: Crypto Restrictions Unconstitutional - US Court To: ldv@long.yar.ru (Dmitri V. Lukyanov) Date: Sun, 22 Dec 1996 05:54:43 -0800 (PST) Cc: security@freebsd.org In-Reply-To: from "Dmitri V. Lukyanov" at Dec 22, 96 08:46:31 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dmitri V. Lukyanov wrote: > > Hi, > > Is this the end of FreeBSD password encryption problems? NO! this court ruling applies to Mr. Daniel J. Bernstein only. expect the goverment of the USA to appeal the case to a higher court. this may end up at the supreme court due to the first admendment issues that the judge has cited. [snip] > The long-range effects, however, still are cloudy, since Judge > Patel's decision only legally applies to Prof. Bernstein. > > Other people and companies are still technically required to follow > the export restrictions when speaking or publishing about > cryptography, or when speaking or publishing cryptographic source > code. > > The decision, however, sends a strong signal that if the government > tried to enforce these rules against other people, the courts are > likely to strike them down again, Godwin said. jmb From owner-freebsd-security Sun Dec 22 07:06:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA06218 for security-outgoing; Sun, 22 Dec 1996 07:06:21 -0800 (PST) Received: from server.fasts.com (root@server.fasts.com [199.125.215.66]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA06210 for ; Sun, 22 Dec 1996 07:06:16 -0800 (PST) Received: from server.fasts.com ([199.125.215.66]) by fasts.com with SMTP id <115-222>; Sun, 22 Dec 1996 17:06:11 +0000 Date: Sun, 22 Dec 1996 17:06:06 +0000 () From: Victor Rotanov To: freebsd-security@FreeBSD.org Subject: seems like procfs bug... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi guys. Heres the problem: There is r-xr-xr-x file in rwx------ directory. When i run it, everyone is able to read it from /proc//file. Seems like a bug, eh? Thanks, bye. vitjok From owner-freebsd-security Sun Dec 22 08:02:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA08805 for security-outgoing; Sun, 22 Dec 1996 08:02:05 -0800 (PST) Received: from maple.sover.net (root@maple.sover.net [204.71.16.11]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA08781; Sun, 22 Dec 1996 08:01:29 -0800 (PST) Received: from [204.71.18.158] (pm1a28.bratt.sover.net [204.71.18.158]) by maple.sover.net (8.8.4/8.8.2) with ESMTP id LAA24031; Sun, 22 Dec 1996 11:00:16 -0500 (EST) Date: Sun, 22 Dec 1996 11:00:16 -0500 (EST) X-Sender: apropos@mail.sover.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: zen@trouble.org From: Apropos of Nothing Subject: Re: CERT, CIAC, etc. unethical practices Cc: security-alert@Sun.COM, cse-security-alert@csd.sgi.com, security@freebsd.org, ciac@llnl.gov, cert@cert.org, security-officer@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The key issue here is respect for the *freedom* of intellectual property. The people of CERT shouldn't be making a judgement call on the people of Bugtraq. People in Bugtraq are not, on the whole, posting code to be malicious, it's just that they believe in the free dissemination of information. CERT's, CIAC's, and others' policies seem to be supporting everything but the free dissemination of information. Here's why: CERT (I'll use CERT as an exmaple), releases code only when someone else has publicly warned of the hole. Does this spread the message of an organization trying to be informative? No, CERT tries to keep holes quiet until absolute dire straights. Take the message from Alan Cox, about slow vendor response, let's all take bets on how fast the patch is going to come now that the exploit has been revealed. Face it, there has come a time when the only way to prompt a patch or public security notice is to tell everyone there's a problem. So what happens if you warn CERT before hand? According to several people on Bugtraq: Nothing. The next problem is, of course, that CERT refuses to recognize the people who found a given hole in the first place. I won't go into this issue since it's been beaten to a dead pulp already. CERT doesn't seem to come up with many of it's own security alerts, when was the last time you saw a CERT alert that hadn't been posted to Bugtraq before hand? How can they flagrantly ignore the people who discover the security holes, when the people who discover the security holes are the only ones doing the dirty work. Finaly, CERT makes a pointed effort to hide expoit information, their advisories can extremely cryptic for this reason, and sometimes they don't even release a patch because it would give away the expoit. Is this free information? You tell me. I hope you can see why these company policies need changing. Since the fault here is not a legal one, but rather a moral one, social action is the only recourse. I propose a letter writing campaign (this does not mean, I repeat DOES NOT MEAN a mail bombing campaign). Everyone should write well thought out letters to the following addresses: CERT - - - - - - - Email: cert@cert.org CIAC - - - - - - - Email: ciac@llnl.gov FreeBSD - - - - - - - Confidential contacts: security-officer@freebsd.org Security public discussion: security@freebsd.org SGI - - - - - - - Email: cse-security-alert@csd.sgi.com SUN - - - - - - - Email: security-alert@Sun.COM Of course, If you feel like your messages are getting ignored at the above adresses, just send the same message to the root user at the server. Apropos of Nothing From owner-freebsd-security Sun Dec 22 09:52:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA14018 for security-outgoing; Sun, 22 Dec 1996 09:52:07 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA14013 for ; Sun, 22 Dec 1996 09:52:04 -0800 (PST) Received: from cwsys (1000@localhost [127.0.0.1]) by cwsys.cwent.com (8.8.4/8.6.10) with ESMTP id JAA00691; Sun, 22 Dec 1996 09:51:38 -0800 (PST) Message-Id: <199612221751.JAA00691@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Victor Rotanov cc: freebsd-security@FreeBSD.org Subject: Re: seems like procfs bug... In-reply-to: Your message of "Sun, 22 Dec 1996 17:06:06 GMT." Date: Sun, 22 Dec 1996 09:51:37 -0800 From: Cy Schubert Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Hi guys. > > Heres the problem: > > There is r-xr-xr-x file in rwx------ directory. > When i run it, everyone is able to read it from /proc//file. > Seems like a bug, eh? > > Thanks, bye. > vitjok > > Maybe I'm missing something. I can't reproduce your problem on my 2.1.5 systems. Regards, Phone: (604)387-8437 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 Sun Dec 22 09:54:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA14093 for security-outgoing; Sun, 22 Dec 1996 09:54:53 -0800 (PST) Received: from server.fasts.com (root@server.fasts.com [199.125.215.66]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA14088 for ; Sun, 22 Dec 1996 09:54:47 -0800 (PST) Received: from server.fasts.com ([199.125.215.66]) by fasts.com with SMTP id <115-223>; Sun, 22 Dec 1996 19:54:39 +0000 Date: Sun, 22 Dec 1996 19:54:38 +0000 () From: Victor Rotanov To: cschuber@uumail.gov.bc.ca cc: freebsd-security@FreeBSD.org Subject: Re: seems like procfs bug... In-Reply-To: <199612221751.JAA00691@cwsys.cwent.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 Hello Cy! On Sun, 22 Dec 1996, Cy Schubert wrote: > > > > Hi guys. > > > > Heres the problem: > > > > There is r-xr-xr-x file in rwx------ directory. > > When i run it, everyone is able to read it from /proc//file. > > Seems like a bug, eh? > > > > > Maybe I'm missing something. I can't reproduce your problem on my 2.1.5 > systems. I'm running 2.2 and i never tried this on 2.1.5. > > > Regards, Phone: (604)387-8437 > 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 Sun Dec 22 16:48:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA29683 for security-outgoing; Sun, 22 Dec 1996 16:48:14 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA29678 for ; Sun, 22 Dec 1996 16:48:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id QAA23206; Sun, 22 Dec 1996 16:47:02 -0800 (PST) Message-Id: <199612230047.QAA23206@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Victor Rotanov cc: cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org Subject: Re: seems like procfs bug... In-reply-to: Your message of "Sun, 22 Dec 1996 19:54:38 GMT." From: David Greenman Reply-To: dg@root.com Date: Sun, 22 Dec 1996 16:47:02 -0800 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> > Heres the problem: >> > >> > There is r-xr-xr-x file in rwx------ directory. >> > When i run it, everyone is able to read it from /proc//file. >> > Seems like a bug, eh? >> > >> >> >> Maybe I'm missing something. I can't reproduce your problem on my 2.1.5 >> systems. > >I'm running 2.2 and i never tried this on 2.1.5. 2.1.5 had the 'file' disabled because it didn't work right. We should probably kill it in 2.2, too, but only because it isn't very useful and (as you've pointed out) creates a security hole. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Sun Dec 22 17:52:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA02175 for security-outgoing; Sun, 22 Dec 1996 17:52:04 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA02153 for ; Sun, 22 Dec 1996 17:52:00 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA15361; Mon, 23 Dec 1996 12:21:33 +1030 (CST) From: Michael Smith Message-Id: <199612230151.MAA15361@genesis.atrad.adelaide.edu.au> Subject: Re: seems like procfs bug... In-Reply-To: <199612230047.QAA23206@root.com> from David Greenman at "Dec 22, 96 04:47:02 pm" To: dg@root.com Date: Mon, 23 Dec 1996 12:21:32 +1030 (CST) Cc: vitjok@fasts.com, cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (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 David Greenman stands accused of saying: > > 2.1.5 had the 'file' disabled because it didn't work right. We should > probably kill it in 2.2, too, but only because it isn't very useful and > (as you've pointed out) creates a security hole. It should perhaps be replaced with a 'path' item, which contains the path to the executable, so that things like debuggers which might want to access the disk file in conjunction with the memory image can still access this information. > David Greenman -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Sun Dec 22 20:53:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA15883 for security-outgoing; Sun, 22 Dec 1996 20:53:37 -0800 (PST) Received: from rhiannon.clari.net.au (dns1.clari.net.au [203.27.85.9]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA15875 for ; Sun, 22 Dec 1996 20:53:28 -0800 (PST) Received: (from peter@localhost) by rhiannon.clari.net.au (8.7.5/8.6.12) id PAA04079; Mon, 23 Dec 1996 15:51:49 +1100 (EST) Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199612230047.QAA23206@root.com> Date: Mon, 23 Dec 1996 15:50:11 +1100 (EST) Organization: ClariNET Internet Servies From: Peter Hawkins To: dg@root.com Subject: Re: seems like procfs bug... Cc: David Greenman , Victor Rotanov , cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk David, I just wondered if you'd mind trying to boot your copy off my floppy image as I cannot find anything obviously wrong. Suddenly it starts executing a different lot of instructions from the older version of pcemu after 100 or so... Peter ---------------------------------- Peter Hawkins E-Mail: Peter Hawkins Ph: 61 3 9852 7340 ClariNET Internet Services http://www.clari.net.au ---------------------------------- From owner-freebsd-security Sun Dec 22 20:54:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA15918 for security-outgoing; Sun, 22 Dec 1996 20:54:32 -0800 (PST) Received: from obie.softweyr.com (slc196.modem.xmission.com [204.228.136.196]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA15913 for ; Sun, 22 Dec 1996 20:54:25 -0800 (PST) Received: (from wes@localhost) by obie.softweyr.com (8.7.5/8.6.12) id VAA00471; Sun, 22 Dec 1996 21:54:33 -0700 (MST) Date: Sun, 22 Dec 1996 21:54:33 -0700 (MST) Message-Id: <199612230454.VAA00471@obie.softweyr.com> From: Wes Peters To: Apropos of Nothing CC: security@freebsd.org Subject: Re: CERT, CIAC, etc. unethical practices In-Reply-To: References: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Apropos of Nothing writes: > CERT's, CIAC's, and others' policies seem to be supporting everything but > the free dissemination of information. CERT in particular is chartered to work as a clearinghouse for computer security related information. They don't normally disseminate data unless you contact them with a problem; they will tell you if your problem has been previously reported, but not how many times or how often. In a former lifetime, I created a commercial software product to analyze the security configuration of UNIX systems and report on deviations from a user-configured baseline. We contacted CERT several times asking for participation in this product. We were informed that CERT a) doesn't participate in commercial software development other than to forward reports to the system vendors (and no one else), and b) even if they did actually do security analysis, they weren't interested in analyzing commercial UNIX distributions in order to create recommended security configurations. In short, CERT doesn't *want* to really learn about computer security, just to hoard information about it. Open disclosure works because it means the system administrators and developers get timely and accurate information about exploits so they can close the holes. If you run a security sensitive system attached to a network, you should probably follow bugtraq alerts carefully. Watch CERT advisories also, but don't expect them to tell you much other than "call your vendor and mention this CERT adivsory number." -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Sun Dec 22 20:55:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA15944 for security-outgoing; Sun, 22 Dec 1996 20:55:25 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA15937 for ; Sun, 22 Dec 1996 20:55:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA24284; Sun, 22 Dec 1996 20:53:55 -0800 (PST) Message-Id: <199612230453.UAA24284@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Peter Hawkins cc: Victor Rotanov , cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org Subject: Re: seems like procfs bug... In-reply-to: Your message of "Mon, 23 Dec 1996 15:50:11 +1100." From: David Greenman Reply-To: dg@root.com Date: Sun, 22 Dec 1996 20:53:55 -0800 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >I just wondered if you'd mind trying to boot your copy off my floppy image >as I cannot find anything obviously wrong. Suddenly it starts executing >a different lot of instructions from the older version of pcemu after 100 >or so... Huh? I seem to be missing some context. What are you talking about? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Sun Dec 22 20:57:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA16045 for security-outgoing; Sun, 22 Dec 1996 20:57:52 -0800 (PST) Received: from rhiannon.clari.net.au (dns1.clari.net.au [203.27.85.9]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA16040 for ; Sun, 22 Dec 1996 20:57:42 -0800 (PST) Received: (from peter@localhost) by rhiannon.clari.net.au (8.7.5/8.6.12) id PAA04142; Mon, 23 Dec 1996 15:57:23 +1100 (EST) Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199612230453.UAA24284@root.com> Date: Mon, 23 Dec 1996 15:57:02 +1100 (EST) Organization: ClariNET Internet Servies From: Peter Hawkins To: dg@root.com Subject: Re: seems like procfs bug... Cc: David Greenman , Victor Rotanov , cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Ooops - wrong message I replied to sorry. Peter ---------------------------------- Peter Hawkins E-Mail: Peter Hawkins Ph: 61 3 9852 7340 ClariNET Internet Services http://www.clari.net.au ---------------------------------- From owner-freebsd-security Sun Dec 22 23:21:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA22671 for security-outgoing; Sun, 22 Dec 1996 23:21:23 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA22653 for ; Sun, 22 Dec 1996 23:21:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.3/8.8.3) with SMTP id WAA12564; Sun, 22 Dec 1996 22:50:39 -0800 (PST) Date: Sun, 22 Dec 1996 22:50:37 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: David Greenman cc: Victor Rotanov , cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.org Subject: Re: seems like procfs bug... In-Reply-To: <199612230047.QAA23206@root.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 Sun, 22 Dec 1996, David Greenman wrote: > >> > Heres the problem: > >> > > >> > There is r-xr-xr-x file in rwx------ directory. > >> > When i run it, everyone is able to read it from /proc//file. > >> > Seems like a bug, eh? > >> > > >> > >> > >> Maybe I'm missing something. I can't reproduce your problem on my 2.1.5 > >> systems. > > > >I'm running 2.2 and i never tried this on 2.1.5. > > 2.1.5 had the 'file' disabled because it didn't work right. We should > probably kill it in 2.2, too, but only because it isn't very useful and > (as you've pointed out) creates a security hole. why not change the default permision to what the file was? or at least owned by root and 0600? because even though a path is useful... what happens if some one simply "replaces" the binary on the disk.... with the file you can nab a copy of a possible snifer program ever after the "hacker" has removed it from the drive... just a few thoughts... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-security Mon Dec 23 20:18:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA07747 for security-outgoing; Mon, 23 Dec 1996 20:18:08 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id UAA07742 for ; Mon, 23 Dec 1996 20:18:00 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id UAA02751 for ; Mon, 23 Dec 1996 20:17:54 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Mon, 23 Dec 1996 20:17:51 -0800 (PST) From: Steve Reid To: freebsd-security@freebsd.org Subject: Holes in default cron jobs (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Mon, 23 Dec 1996 20:26:02 -0700 From: David Sacerdote To: Multiple recipients of list BUGTRAQ Subject: Holes in default cron jobs ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. Security Advisory December 23, 1996 Vulnerabilities in Default Cron Jobs We have become aware of serious problems relating to the handling of temporary files by the default BSD cron jobs /etc/security and later became aware of an equally serious problem in /etc/daily. In addition, the 4.4BSDlite2 version of /etc/security passes unchecked data to a shell. These bugs make it possible for unpriviliged users to obtain root access, EVEN IF THERE ARE NO SETUID PROGRAMS ON THE SYSTEM. Technical Details ~~~~~~~~~~~~~~~~~ The first problem with /etc/security is that it passes unchecked data to a shell. If a user creates a file whose name contains shell metacharacters and makes it executable and setuid, /etc/security will gladly execute commands specified in the name of the file as root. The problem is the big find line used to search for setuid files, which in 4.4BSDlite2 reads: (find / ! -fstype local -a -prune -o \ \( -perm -u+s -o -perm -g+s -o ! -type d -a ! -type f -a ! -type l -a \ ! -type s \) | \ sort | sed -e 's/^/ls -ldgT /' | sh > $LIST) 2> $OUTPUT The second problem with /etc/security is its poor use of temporary files. In 4.4BSDLite2 /etc/security uses six temporary files unsafely. They are all named /tmp/_secure?.$$, where ? is a number in the range 1 through 6, and $$ is replaced with the process id of the shell interpreting /etc/security at run time. A malicious user needs merely to run an at job a minute before /etc/security which creates symlinks named /tmp/_secure?.$$, and wait for the cron job to overwrite the file of his choice. In addition, the user has much control over the contents of some of these temporary files, allowing users to obtain root access. Similarly, the /etc/daily script search for core files to be deleted can be induced to corrupt arbitrary files, and even create valid .rhosts files. By creating files with names like: + + #.core and leaving an appropriate symbolic link in /tmp, users can obtain root priviliges. These are doubtless not the only shell scripts with /tmp problems, and 4.4BSD is certainly not alone in having these kinds of problems. However, given the wide availiblity of source to shell scripts which ship with operating systems, it is fairly easy for the informed system administrator to determine whether scripts on his system are vulnerable. Impact ~~~~~~ Users with a valid account can obtain root priviliges even if there are no setuid programs on the system. Vulnerable Systems ~~~~~~~~~~~~~~~~~~ 4.4BSDlite derived unixes are likely to be vulnerable to the particular default cron job problems described here. OpenBSD 2.0 is vulnerable to the /etc/daily problem, which is fixed in OpenBSD-current. OpenBSD 2.0 is not vulnerable to any of the problems in /etc/security. FreeBSD 2.1.5 is vulnerable to the /tmp problems in /etc/security and but does not pass unchecked data to a shell in /etc/security, or have a /tmp related problem in /etc/daily. BSD/OS 2.0 is vulnerable to the problems in /etc/security, but not the problem in /etc/daily. We have not checked a more recent release of BSD/OS. NetBSD 1.2 is vulnerable to all three problems. 4.4BSDlite2 is vulnerable to all three problems. Note that the vulnerability information for BSD/OS, NetBSD, and 4.4BSDlite2 is based exclusively on source inspection. Be aware that even if not vulnerable to these specific problems, virtually every operating system has at least one shell script which does not safely handle temporary files. Given the availibility of source code to shell scripts, operating system vendors would do well to make them a showcase of good programming practices. Fix Information ~~~~~~~~~~~~~~~ The version of /etc/security in OpenBSD 2.0 appears safe, as does the version of /etc/daily in OpenBSD-current. On most operating systems, mkdir is both atomic, and does not follow symbolic links. Therefore it is possible to use mkdir in a shell script to write portable and secure code. # A viable /etc/security, which requires OpenBSD or GNU # find and xargs. # note that this version lacks features found in the 4.4Lite2 # /etc/security. #------------------------- cut here ----------------------------- #!/bin/sh # PATH=/sbin:/bin:/usr/bin LC_ALL=C; export LC_ALL host=`hostname -s` echo "Subject: $host security check output" LOG=/var/log umask 077 TDIR=/tmp/_secure.$$ if ! mkdir $TDIR ; then echo $TDIR already exists ls -alF $TDIR exit 1 fi TMP=$TDIR/secure trap 'rm -rf $TDIR' 0 1 2 3 4 5 6 7 8 10 11 12 13 14 15 echo "checking setuid files and devices:" find / -fstype local -and -type f -and \ \( -perm 4000 -or -perm 2000 \) -print0 | sort \ | xargs -0 ls -lgTd > $TMP if [ ! -f $LOG/setuid.today ] ; then echo "no $LOG/setuid.today" cp $TMP $LOG/setuid.today fi if cmp $LOG/setuid.today $TMP >/dev/null; then :; else echo "$host setuid diffs:" diff -b $LOG/setuid.today $TMP mv $LOG/setuid.today $LOG/setuid.yesterday mv $TMP $LOG/setuid.today fi rm -f $TMP #------------------------- cut here ----------------------------- # A viable /etc/daily based around the OpenBSD one: #------------------------- cut here ----------------------------- #!/bin/sh - PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local host=`hostname -s` echo "Subject: $host daily run output" if [ -f /etc/daily.local ];then echo "" echo "Running daily.local:" . /etc/daily.local fi UMASK=`umask` umask 077 TDIR=/tmp/_daily.$$ if ! mkdir $TDIR ; then echo $TDIR already exists echo ls -ldgT $TDIR exit 1 fi umask $UMASK TMP=$TDIR/daily trap 'rm -rf $TDIR' 0 1 2 3 4 5 6 7 8 10 11 12 13 14 15 echo "" echo "NOT Removing scratch and junk files." find / \( ! -fstype local -o -fstype rdonly -o -fstype fdesc \ -o -fstype kernfs -o -fstype procfs \) -a -prune -o \ -name 'lost+found' -a -prune -o \ -name '*.core' -a -print > $TMP if egrep -q '\.core$' $TMP; then echo "" echo "Possible core dumps:" egrep '\.core$' $TMP fi msgs -c if [ -f /etc/news.expire ]; then /etc/news.expire fi if [ -f /var/account/acct ]; then echo "" ; echo "Purging accounting records:" ; mv /var/account/acct.2 /var/account/acct.3 ; mv /var/account/acct.1 /var/account/acct.2 ; mv /var/account/acct.0 /var/account/acct.1 ; cp /var/account/acct /var/account/acct.0 ; sa -sq ; fi echo "" if [ -d /var/yp/binding -a ! -d /var/yp/`domainname` ]; then echo "Not running calendar, (yp client)." else echo "Running calendar." calendar -a fi # Rotation of mail log now handled automatically by cron and 'newsyslog' if [ -d /var/spool/uucp -a -f /etc/uuclean.daily ]; then echo "" echo "Cleaning up UUCP:" echo /etc/uuclean.daily | su daemon fi echo "" echo "Checking subsystem status:" echo "" echo "disks:" df -k echo "" dump W echo "" mailq > $TMP if ! grep -q "^Mail queue is empty$" $TMP; then echo "" echo "mail:" cat $TMP fi if [ -d /var/spool/uucp ]; then uustat -a > $TMP if [ -s $TMP ]; then echo "" echo "uucp:" cat $TMP fi fi echo "" echo "network:" netstat -i echo "" t=/var/rwho/* if [ "$t" != '/var/rwho/*' ]; then ruptime fi echo "" echo "NOT checking filesystems." #echo "Checking filesystems:" #fsck -n | grep -v '^\*\* Phase' echo "" if [ -f /etc/Distfile ]; then echo "Running rdist:" rdist -f /etc/Distfile fi sh /etc/security 2>&1 | mail -s "$host daily insecurity output" root #------------------------- cut here ----------------------------- Additional Information ~~~~~~~~~~~~~~~~~~~~~~ You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/pub/advisories If you have questions or comments about this advisory, please contact David Sacerdote, davids@secnet.com. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJ4qJAAAAEEAOgB7mooQ6NgzcUSIehKUufGsyojutC7phVXZ+p8FnHLLZNB BLQEtj5kmfww2A2pR29q4rgPeqEUOjWPlLNdSLby3NI8yKz1AQSQLHAwIDXt/lku 8QXClaV6pNIaQSN8cnyyvjH6TYF778yZhYz0mwLqW6dU5whHtP93ojDw1UhtAAUR tCtEYXZpZCBTYWNlcmRvdGUgPGRhdmlkc0BzaWxlbmNlLnNlY25ldC5jb20+ =LtL9 -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1996 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and proper credit is given. Source code distributed with this advisory falls under the following license: Copyright (c) 1989, 1993, 1994 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. From owner-freebsd-security Mon Dec 23 20:19:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA07778 for security-outgoing; Mon, 23 Dec 1996 20:19:05 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id UAA07771 for ; Mon, 23 Dec 1996 20:18:58 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id UAA02759 for ; Mon, 23 Dec 1996 20:18:54 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Mon, 23 Dec 1996 20:18:53 -0800 (PST) From: Steve Reid Reply-To: Steve Reid To: freebsd-security@freebsd.org Subject: Re: Holes in default cron jobs (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The only problem they mention in FreeBSD is in /etc/security. Rather than use the OpenBSD /etc/security, I've copied the tmp file change into FreeBSD's /etc/security. I'm running 2.1.6.1-RELEASE, but the machine was originally a 2.1.0-RELEASE... Has the /etc/security been updated since then? Here's my modified /etc/security. Let me know what you think. #!/bin/sh - # # @(#)security 5.3 (Berkeley) 5/28/91 # $Id: security,v 1.8 1995/05/27 01:37:44 ache Exp $ # PATH=/sbin:/bin:/usr/bin host=`hostname -s` echo "Subject: $host security check output" LOG=/var/log TDIR=/tmp/_secure.$$ umask 027 # Here's my modification, also rmdir later if ! mkdir $TDIR ; then echo $TDIR already exists ls -alF $TDIR exit 1 fi TMP=$TDIR/secure echo "checking setuid files and devices:" # don't have ncheck, but this does the equivalent of the commented out block. # note that one of the original problem, the possibility of overrunning # the args to ls, is still here... # MP=`mount -t ufs | sed 's;/dev/;&r;' | awk '{ print $3 }'` set $MP while test $# -ge 1; do mount=$1 shift find $mount -xdev \( -perm -u+s -or -perm -g+s \) | sort done | xargs -n 20 ls -lgTd > $TMP if cmp $LOG/setuid.today $TMP >/dev/null; then :; else echo "$host setuid/device diffs:" diff -b $LOG/setuid.today $TMP mv $LOG/setuid.today $LOG/setuid.yesterday mv $TMP $LOG/setuid.today fi rm -f $TMP rmdir $TDIR echo "" echo "" echo "checking for uids of 0:" awk 'BEGIN {FS=":"} $3=="0" {print $1,$3}' /etc/master.passwd From owner-freebsd-security Mon Dec 23 22:01:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA10447 for security-outgoing; Mon, 23 Dec 1996 22:01:43 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA10442 for ; Mon, 23 Dec 1996 22:01:41 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id XAA03966; Mon, 23 Dec 1996 23:01:34 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id XAA23263; Mon, 23 Dec 1996 23:01:35 -0700 (MST) Date: Mon, 23 Dec 1996 23:01:35 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Steve Reid cc: freebsd-security@freebsd.org Subject: Re: Holes in default cron jobs (fwd) 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 NOTE: anyone running a -stable system should apply something resembling the patch included below. While some kind soul (hint, hint) may commit the below change to -stable, it won't have too much effect since few people reinstall /etc. Anyone running -current should check to be sure their /etc/security is an updated one. On Mon, 23 Dec 1996, Steve Reid wrote: > The only problem they mention in FreeBSD is in /etc/security. Rather than > use the OpenBSD /etc/security, I've copied the tmp file change into > FreeBSD's /etc/security. It is generally better to append a context diff (diff -u; or my preffered format, -c) instead of the file; regardless of how short it is, it makes it easier to see what has changed. > > I'm running 2.1.6.1-RELEASE, but the machine was originally a > 2.1.0-RELEASE... Has the /etc/security been updated since then? There have been some changes that have not made it to -stable, notably: pst 96/07/30 23:47:06 Modified: etc security Log: Move intermediary file generation to /var partition Revision Changes Path 1.14 +2 -2 src/etc/security This change simply does: ----snip---- --- security 1996/06/30 19:35:20 1.13 +++ security 1996/07/31 06:47:05 1.14 @@ -15,7 +15,7 @@ echo "Subject: $host security check output" LOG=/var/log -TMP=/tmp/_secure.$$ +TMP=/var/run/_secure.$$ umask 027 ----snip---- which secures it by using /var/run, which shouldn't be world writable. > Here's my modified /etc/security. Let me know what you think. > > > #!/bin/sh - > # > # @(#)security 5.3 (Berkeley) 5/28/91 > # $Id: security,v 1.8 1995/05/27 01:37:44 ache Exp $ > # > PATH=/sbin:/bin:/usr/bin > > host=`hostname -s` > echo "Subject: $host security check output" > > LOG=/var/log > TDIR=/tmp/_secure.$$ > > umask 027 (general comment; not about your patch) I would prefer 077 instead of 027. It doesn't hurt right now, and nothing that confidential is written to $TDIR, but... some day... somep place... > > # Here's my modification, also rmdir later > if ! mkdir $TDIR ; then > echo $TDIR already exists > ls -alF $TDIR > exit 1 > fi > TMP=$TDIR/secure Why not do it as a trap that calls 'rm -rf $TDIR' like the bulletin suggests? Makes sure it gets deleted, even if some file exists in it or it exits early for some reason. Your patch does fix the problem, but isn't necessary in -current. From owner-freebsd-security Mon Dec 23 23:06:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA12124 for security-outgoing; Mon, 23 Dec 1996 23:06:36 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA12113 for ; Mon, 23 Dec 1996 23:06:34 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA24145 for ; Mon, 23 Dec 1996 23:06:48 -0800 (PST) Received: (qmail 29963 invoked by uid 110); 24 Dec 1996 07:05:24 -0000 Message-ID: <19961224070524.29962.qmail@suburbia.net> Subject: Re: Holes in default cron jobs (fwd) In-Reply-To: from Marc Slemko at "Dec 23, 96 11:01:35 pm" To: marcs@znep.com (Marc Slemko) Date: Tue, 24 Dec 1996 18:05:24 +1100 (EST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > NOTE: anyone running a -stable system should apply something resembling > the patch included below. While some kind soul (hint, hint) may commit > the below change to -stable, it won't have too much effect since few > people reinstall /etc. Anyone running -current should check to be sure > their /etc/security is an updated one. > > On Mon, 23 Dec 1996, Steve Reid wrote: > > > The only problem they mention in FreeBSD is in /etc/security. Rather than > > use the OpenBSD /etc/security, I've copied the tmp file change into > > FreeBSD's /etc/security. > > It is generally better to append a context diff (diff -u; or my > preffered format, -c) instead of the file; regardless of how short it > is, it makes it easier to see what has changed. > > > > > I'm running 2.1.6.1-RELEASE, but the machine was originally a > > 2.1.0-RELEASE... Has the /etc/security been updated since then? My solution to the /tmp/foo problem is: for n in `awk -F: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA02933 for security-outgoing; Tue, 24 Dec 1996 12:17:06 -0800 (PST) Received: from selkirk.csrv.nidc.edu (selkirk.csrv.nidc.edu [192.133.128.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA02927 for ; Tue, 24 Dec 1996 12:17:03 -0800 (PST) Received: by selkirk.csrv.nidc.edu (1.38.193.5/16.2) id AA10042; Tue, 24 Dec 1996 12:18:11 -0800 Date: Tue, 24 Dec 1996 12:18:11 -0800 (PST) From: Mark Nottage To: security-digest@freefall.freebsd.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-security Tue Dec 24 13:57:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA06097 for security-outgoing; Tue, 24 Dec 1996 13:57:54 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA06091 for ; Tue, 24 Dec 1996 13:57:51 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.6.12/8.6.12) with ESMTP id PAA274884; Tue, 24 Dec 1996 15:57:50 -0600 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id PAA23404; Tue, 24 Dec 1996 15:56:21 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199612242156.PAA23404@alecto.physics.uiuc.edu> Subject: Re: Holes in default cron jobs (fwd) To: marcs@znep.com (Marc Slemko) Date: Tue, 24 Dec 1996 15:56:21 -0600 (CST) Cc: steve@edmweb.com, freebsd-security@freebsd.org In-Reply-To: from "Marc Slemko" at Dec 23, 96 11:01:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Modified: etc security > Log: > Move intermediary file generation to /var partition > > Revision Changes Path > 1.14 +2 -2 src/etc/security > > This change simply does: > > ----snip---- > --- security 1996/06/30 19:35:20 1.13 > +++ security 1996/07/31 06:47:05 1.14 > @@ -15,7 +15,7 @@ > echo "Subject: $host security check output" > > LOG=/var/log > -TMP=/tmp/_secure.$$ > +TMP=/var/run/_secure.$$ > > umask 027 > > ----snip---- > > which secures it by using /var/run, which shouldn't be world writable. Excuse me, I was wondering (it might be stupid, 'cause I am probably about something), why don't do a simple check for existence of the file, something like if ( -f $TMP ) then rm -rf $TMP endif Thanks for the answers, and Merry X-mas and Happy New Year! IgoR aka StR From owner-freebsd-security Tue Dec 24 14:36:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA07649 for security-outgoing; Tue, 24 Dec 1996 14:36:20 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA07644 for ; Tue, 24 Dec 1996 14:36:17 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id OAA00704; Tue, 24 Dec 1996 14:36:04 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Tue, 24 Dec 1996 14:36:01 -0800 (PST) From: Steve Reid To: Igor Roshchin cc: freebsd-security@freebsd.org Subject: Re: Holes in default cron jobs (fwd) In-Reply-To: <199612242156.PAA23404@alecto.physics.uiuc.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 > Excuse me, I was wondering (it might be stupid, 'cause I am probably > about something), why don't do a simple check for existence of the file, > something like > > if ( -f $TMP ) then > rm -rf $TMP > endif Possible race condition. What if the attacker replaces the $TMP file with a symlink, _after_ you perform that test, but _before_ you use create the actual file? while true; do ln -s /etc/passwd /tmp/secure_12345; done Also, an attacker could set up a whole bunch of processes to take CPU time away from the cron job, giving him lots of time between your test and the creation of the actual file. Who would notice such a thing at 2am? With all of the attention given to buffer overflows recently, it's easy to forget about race conditions and improper /tmp usage. From owner-freebsd-security Tue Dec 24 20:19:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA26098 for security-outgoing; Tue, 24 Dec 1996 20:19:10 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA26088 for ; Tue, 24 Dec 1996 20:19:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.3/8.8.3) with SMTP id SAA13701 for ; Tue, 24 Dec 1996 18:41:25 -0800 (PST) Date: Tue, 24 Dec 1996 18:41:25 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@hydrogen Reply-To: John-Mark Gurney To: freebsd-security@freefall.freebsd.org Subject: attempted root login gives refused message when password correct instead of login incorrect... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk well.. I just noticed that if you telnet in and try to login as with the the correct password... you get the refused message instead of the login incorrect message... this seems a security whole as you can "obtain" the root password through this method... am I being overly worried? I have a patch that will report login incorrect when it's root when it was actually refused... this doesn't change the syslog entry... just want the user sees... thanks for your time... John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-security Tue Dec 24 20:54:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA27065 for security-outgoing; Tue, 24 Dec 1996 20:54:13 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA27058 for ; Tue, 24 Dec 1996 20:54:11 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id VAA29000; Tue, 24 Dec 1996 21:54:09 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id VAA29708; Tue, 24 Dec 1996 21:53:21 -0700 (MST) Date: Tue, 24 Dec 1996 21:53:21 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: John-Mark Gurney cc: freebsd-security@freefall.freebsd.org Subject: Re: attempted root login gives refused message when password correct instead of login incorrect... 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, 24 Dec 1996, John-Mark Gurney wrote: > well.. I just noticed that if you telnet in and try to login as with the > the correct password... you get the refused message instead of the login > incorrect message... this seems a security whole as you can "obtain" the > root password through this method... > > am I being overly worried? I have a patch that will report login > incorrect when it's root when it was actually refused... this doesn't > change the syslog entry... just want the user sees... The idea is that is you know the root password, then you have already been authenticated as root so no information is being given away. If you are going to try something like a dictionary attack then I guess it does make something of a difference, but if such an attack can guess root's password I think you have bigger problems. I think that the primary reason that it explicitly states that root login is refused on the terminal is so that people know why they can't login as root when they try, and don't get confused thinking they have the wrong password. I'm not sure it is a big issue. From owner-freebsd-security Wed Dec 25 00:17:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA01663 for security-outgoing; Wed, 25 Dec 1996 00:17:10 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA01654; Wed, 25 Dec 1996 00:17:01 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id AAA02719; Wed, 25 Dec 1996 00:16:50 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Wed, 25 Dec 1996 00:16:47 -0800 (PST) From: Steve Reid To: bugtraq@netspace.org, security@freebsd.org, security-officer@freebsd.org Subject: Another buggy root cron job Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Another cron job temp file bug that affects FreeBSD and possibly others. /usr/libexec/locate.updatedb is called from /etc/weekly. It has _exactly_ the same problem as /etc/security with it's opening temp files. By default, it uses /var/tmp instead of /tmp, but they're both mode 1777 so it doesn't make any difference. I was able to overwrite my own /etc/master.passwd by just creating a symlink (as a normal user) and running locate.updatedb (as root). I don't know if the content of the files can be manipulated enough to gain root, but users being able to munge any file on the system is not a Good Thing. This was on a FreeBSD 2.1.0-RELEASE system. The locate.updatedb is identical on my 2.1-stable (which is now 2.1.6.1-RELEASE) machine. The easiest fix for this is the same as the easiest fix for /etc/security: use a root-only directory such as /var/run instead of something world writable. There's a handy line for this in the script: if (! $?TMPDIR) setenv TMPDIR /var/tmp Change it to if (! $?TMPDIR) setenv TMPDIR /var/run ^^^ or just setenv TMPDIR /var/run Merry Christmas. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEVAwUBMsDgzNtVWdufMXJpAQGEhggAn5UsdxLMi0+vTvS2PY/2WpV6l7aBIRh0 pVYIu7lEijxxggyVFSkhQIiVs+qJENxzATjDjehu4Y9vRE/Lt2TFMOwYghXUo5/B PVTFlvhQUPBI3TNO7h4v5eLhiLhQdmxXfxpE2jEdouQ7OBD7F6Yeiz+FSSd+0dNo bt2TsHqWohpgyKc2DZRqa9gElzQSemn/frQcTnpRKGe0y2fZQI3UcC4f9qM//0GR EL/bKzZEDNvrHByDBFWgs7XTctjD1wQvlkOt3H0xWwqzzQKm18XNVJMBSZuBfkDa Fp5+5QtnXh+NbwI1qhvwYYC+D0P3jTIvdXxfz6GTF1eI4SjN6H345A== =WyHw -----END PGP SIGNATURE----- From owner-freebsd-security Wed Dec 25 01:04:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA02820 for security-outgoing; Wed, 25 Dec 1996 01:04:03 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA02785 for ; Wed, 25 Dec 1996 01:03:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.3/8.8.3) with SMTP id BAA14894; Wed, 25 Dec 1996 01:03:13 -0800 (PST) Date: Wed, 25 Dec 1996 01:03:10 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@hydrogen Reply-To: John-Mark Gurney To: Marc Slemko cc: freebsd-security@freefall.freebsd.org Subject: Re: attempted root login gives refused message when password correct instead of login incorrect... 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, 24 Dec 1996, Marc Slemko wrote: > On Tue, 24 Dec 1996, John-Mark Gurney wrote: > > > well.. I just noticed that if you telnet in and try to login as with the > > the correct password... you get the refused message instead of the login > > incorrect message... this seems a security whole as you can "obtain" the > > root password through this method... > > > > am I being overly worried? I have a patch that will report login > > incorrect when it's root when it was actually refused... this doesn't > > change the syslog entry... just want the user sees... > > The idea is that is you know the root password, then you have already been > authenticated as root so no information is being given away. If you are > going to try something like a dictionary attack then I guess it does make > something of a difference, but if such an attack can guess root's password > I think you have bigger problems. that probably is true... > I think that the primary reason that it explicitly states that root login > is refused on the terminal is so that people know why they can't login as > root when they try, and don't get confused thinking they have the wrong > password. that is a good point... > I'm not sure it is a big issue. I didn't think so... oh well... glad to get your thoughts on the subject... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-security Wed Dec 25 01:34:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA03735 for security-outgoing; Wed, 25 Dec 1996 01:34:47 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA03727; Wed, 25 Dec 1996 01:34:37 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id BAA03267; Wed, 25 Dec 1996 01:34:27 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Wed, 25 Dec 1996 01:34:22 -0800 (PST) From: Steve Reid To: bugtraq@netspace.org, security@freebsd.org, security-officer@freebsd.org Subject: FALSE ALARM: Re: Another buggy root cron job 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 My face is very red. >From /etc/weekly: echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\ fgrep -v 'Permission denied' It's run as nobody. From owner-freebsd-security Wed Dec 25 05:46:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA11312 for security-outgoing; Wed, 25 Dec 1996 05:46:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA11286; Wed, 25 Dec 1996 05:45:59 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA26072; Thu, 26 Dec 1996 00:45:28 +1100 Date: Thu, 26 Dec 1996 00:45:28 +1100 From: Bruce Evans Message-Id: <199612251345.AAA26072@godzilla.zeta.org.au> To: bugtraq@netspace.org, security-officer@freebsd.org, security@freebsd.org, steve@edmweb.com Subject: Re: FALSE ALARM: Re: Another buggy root cron job Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >My face is very red. > >>From /etc/weekly: >echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\ > fgrep -v 'Permission denied' > >It's run as nobody. Indeed. There's a similar potential hole in mkdep. This hole is a bit larger than the one for the race in mktemp(). No one runs `make depend' or compiles things as root on public machines, right? ;-) Bruce From owner-freebsd-security Thu Dec 26 20:55:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA01911 for security-outgoing; Thu, 26 Dec 1996 20:55:42 -0800 (PST) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA01906 for ; Thu, 26 Dec 1996 20:55:38 -0800 (PST) Received: from zot.io.org (taob@zot.io.org [198.133.36.82]) by post.io.org (8.8.3/8.7.3) with SMTP id XAA07321 for ; Thu, 26 Dec 1996 23:55:21 -0500 (EST) Date: Thu, 26 Dec 1996 23:55:21 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: ANNOUNCE: Crack v5.0a available... (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Sat, 21 Dec 1996 02:13:35 +0000 From: Alec Muffett To: best-of-security@suburbia.net Subject: BoS: ANNOUNCE: Crack v5.0a available... Resent-Date: Sat, 21 Dec 1996 14:39:00 +1100 (EST) Resent-From: best-of-security@suburbia.net Eschewing the media-friendly hype which surrounded the release of SATAN some time ago (Hi Dan!) and bemused by the fact that some of the code he wrote years ago has since crept into the Linux-based operating system of the machine he is composing this message on (as a standard part of the authentication libraries, no less) - the author is pleased to announce the release of: Crack v5.0a - The Password Cracker Crack v6.0 - The Minimalist Password Cracker Crack v7.0 - The Brute-Forcing Password Cracker available from: http://www.users.dircon.co.uk/~crypto/ (just like a London bus, you wait ages and then three turn up at once) In the expectation that some kind soul will be good enough to retrieve copies and place them up for FTP at various well-connected mirror sites (the sundry CERTs, COAST, et al), the MD5 checksum for the first distribution is: 6511dca525b7b921ea09eca855cc58f2 - but please be patient if you *do* suffer problems downloading; it's not like Crack is a new piece of technology, so you shouldn't panic about upgrading. NOTE: Discussion of issues relating to running this version of Crack should be directed to the newsgroup "comp.security.unix" - mention "Crack5" in the subject line. - alec ------------------------------------------------------------------ New features. * Complete restructuring - uses less memory * Ships with Eric Young's "libdes" as standard * API for ease of integration with arbitrary crypt() functions * API for ease of integration with arbitrary passwd file format * Considerably better gecos-field checking * More powerful rule sets * Ability to read dictionaries generated by external commands * Better recovery mechanisms for jobs interrupted by crashes * Easier to control (eg: to put to sleep during working hours) * Bundled with Crack6 (minimalist password cracker) * Bundled with Crack7 (brute force password cracker) * Tested on Solaris, Linux, FreeBSD, NetBSD, OSF and Ultrix ---------------------------------------------------------------------------- Requirements. * Unix-like operating system. * C Compiler. * Moderate amount of disk space. * Lots of CPU time. * PERMISSION FROM YOUR SYSADMIN. * Root-privileges, quite possibly. * "gzip" is extremely desirable. * "perl", if networking/multiprocessing. ------------------------------------------------------------------ ps: I'm quite aware that with the release of a new version of Crack there is bound to be some small amount of controversy generated, particularly from the more "postmodernist" members of the hacker community who will probably denigrate my humble efforts as being "passe" and "nothing new or interesting". What they actually mean is that the methods employed by "Crack" are well-understood (at least by themselves) - no longer sexy, and that it is immensely sad that we still suffer a situation where password cracking is still a pretty effective way of breaking into systems, more than 5 years after I first posted Crack in July 1991. With this, I agree. Even so, this is no reason to say that a new release of Crack is "pointless"; for one thing I would point out that it is precisely because of the availability of Crack that password cracking is "passe" in the community, and as the prime mover behind this change, I feel I am perfectly entitled to waste my spare time in any way I want, including in the provision of a newer version. Secondly, things will not continue to improve unless an evolutionary pressure pewrsists to make people *want* to improve their security; Crack 4.1 was starting to get a bit dog-eared around some of the newer operating systems, and it was time for an update. So it is on that basis that I release this new verion. -- alec muffett, oxford, england please reply to: "alecm" at "crypto.dircon.co.uk" http://www.users.dircon.co.uk/~crypto/ From owner-freebsd-security Fri Dec 27 17:43:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21452 for security-outgoing; Fri, 27 Dec 1996 17:43:27 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21447 for ; Fri, 27 Dec 1996 17:43:22 -0800 (PST) Received: from campa.panke.de (anonymous214.ppp.cs.tu-berlin.de [130.149.17.214]) by mail.cs.tu-berlin.de (8.8.4/8.8.4) with SMTP id CAA05621; Sat, 28 Dec 1996 02:27:44 +0100 (MET) Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id CAA01043; Sat, 28 Dec 1996 02:09:27 +0100 Date: Sat, 28 Dec 1996 02:09:27 +0100 From: Wolfram Schneider Message-Id: <199612280109.CAA01043@campa.panke.de> To: Bruce Evans Cc: security@freebsd.org Subject: Re: FALSE ALARM: Re: Another buggy root cron job In-Reply-To: <199612251345.AAA26072@godzilla.zeta.org.au> References: <199612251345.AAA26072@godzilla.zeta.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: >There's a similar potential hole in mkdep. This hole is a bit larger >than the one for the race in mktemp(). No one runs `make depend' or >compiles things as root on public machines, right? ;-) TMP=_mkdep$$ should fix the problem - it put the temp files into the current working directory. The source tree or object tree should not be world writable ;-) Wolfram