From owner-freebsd-security Tue Jun 25 11:17:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA24994 for security-outgoing; Tue, 25 Jun 1996 11:17:40 -0700 (PDT) Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA24989 for ; Tue, 25 Jun 1996 11:17:38 -0700 (PDT) Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id LAA08889; Tue, 25 Jun 1996 11:17:30 -0700 Received: from edge.minimax.com (minimax.vip.best.com [205.149.169.111]) by shellx.best.com (8.6.12/8.6.5) with SMTP id LAA29401; Tue, 25 Jun 1996 11:15:35 -0700 Message-Id: <199606251815.LAA29401@shellx.best.com> X-Sender: jasonc@best.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 1996 12:26:47 -0700 To: davidg@Root.COM From: Jason Campbell Subject: Re: The Vinnie Loophole Cc: security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Regarding adding checks in /etc/security to scan for '.' in PATH statements, it could be done more simply: 1. /etc/security needs to check for '.' in PATH in the config files in root's home dir. (but nowhere else) 2. 'su' should check for '.' in the PATH when the you're becoming root and warn if it's there (and maybe even take it out). Putting more code in exec() to do this sounds like a really bad idea given how often it's called, and could break things which, for whatever reason, intend to exec something in the current dir. Jason. At 08:38 AM 6/25/96 -0700, you wrote: >>Re: Trojan horse programs that get executed because "." is in PATH >>somewhere: >> >>The fact that this well-known, easily plugged loophole is being >>rediscovered by new admins (probably daily) suggests that we *could* >>do something more proactive to keep it from happening. >> >>1. How about adding checks for "." or equivalent in $PATH to >>/etc/security? Scan for it in .profile, .bashrc, and so forth. This >>would not catch every offence but would help. >> >>2. At appropriate securelevel, have exec() fail with explanation to >>syslog if there is no "/" in argv[0]. How much code would [should] >>this break? Is this a horrible idea? > > It's appropriate for some environments and not for others. I certainly >wouldn't want the kernel involved in this in any case, and things that do >scans through your filesystems need to be carefully controlled. Some systems >have so much disk space and NFS that the scan wouldn't complete within the >24 hour time period. Something like (1), if implemented, should not be enabled >by default. > >-DG > >David Greenman >Core-team/Principal Architect, The FreeBSD Project > >