Date: Tue, 25 Jun 1996 12:26:47 -0700 From: Jason Campbell <jasonc@introrse.com> To: davidg@Root.COM Cc: security@freebsd.org Subject: Re: The Vinnie Loophole Message-ID: <199606251815.LAA29401@shellx.best.com>
next in thread | raw e-mail | index | archive | help
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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606251815.LAA29401>