From owner-freebsd-security Wed Oct 11 1:32:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from static.unixfreak.org (static.unixfreak.org [63.198.170.139]) by hub.freebsd.org (Postfix) with ESMTP id B8ED537B503; Wed, 11 Oct 2000 01:32:43 -0700 (PDT) Received: by static.unixfreak.org (Postfix, from userid 1000) id F387D1F22; Wed, 11 Oct 2000 01:06:28 -0700 (PDT) Subject: Re: ncurses buffer overflows (fwd) In-Reply-To: <20001010214332.G25121@149.211.6.64.reflexcom.com> "from Crist J . Clark at Oct 10, 2000 09:43:32 pm" To: cjclark@alum.mit.edu Date: Wed, 11 Oct 2000 01:06:28 -0700 (PDT) Cc: Robert Watson , "Brian F. Feldman" , Peter Pentchev , achilov@granch.ru, Przemyslaw Frasunek , freebsd-security@FreeBSD.ORG From: Dima Dorfman Reply-To: dima@unixfreak.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20001011080628.F387D1F22@static.unixfreak.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, Oct 11, 2000 at 12:09:59AM -0400, Robert Watson wrote: > > On Tue, 10 Oct 2000, Brian F. Feldman wrote: > > > > Uhm.. it explicitly says '#!/bin/csh' at the start; why are you running > > > > it with 'sh'? > > > > > > The canonical lazy person's execution method for scripts is "shell > > > script.shell", because it is easier than "chmod +x script.shell; ./ > > > script.shell". C shell scripts are supposed to be named .csh for > > > consistency, or nothing at all. > > > > We seem to have some bugs in how shells load and run shell scripts for > > other shells, and in handling of scripts with invalid or bad #! lines at > > the beginning. I think I filed a PR a while ago about handling of scripts > > in single-user mode in particular. If you feel bored someday, you could > > try and fix them :-). The general gyst is the following: shells > > (especially when running in single-user mode for some reason) will tend to > > execute shell scripts themselves, rather than using the interpreter > > defined in the file (not in multi-user mode?). When a failure occurs in > > locating or executing the interpreter, or if interpreters are recursive, > > rather than failing (as the kernel execve call does), it will go ahead and > > execute it using the current shell. Doubt this could be exploited as a > > security bug, but it is probably "wrong". The kernel seems to correctly > > handle layered interpreters by returning an image error (an interpreter > > cannot be another interpreter, preventing recursion). > > Hmmm... I always thought the fact the sh-bang started with a '#' was > part of their magic. When you read in a file with an interpreter, it > reads the file as a flat file. That first line starts with a '#'; it > just a comment, right? What interpreters actually use a sh-bang to > change the interpreter? I thought sh-bangs were only used by exec > calls. "Me too." It was my impression that the whole '#!/path/to/shell' thing started when people expressed a desire to use csh for their scripts, so someone hacked execve in their kernel to look for '#' as the first byte in the file, and if it's there, execute whatever command follows. Since not all kernels had this hack, the script would still get executed with sh on some systems, so it was decided that the sh comment character be used to keep the old hosts happy. Regards -- Dima Dorfman Finger dima@unixfreak.org for my public PGP key. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message