Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Oct 2000 01:06:28 -0700 (PDT)
From:      Dima Dorfman <dima@unixfreak.org>
To:        cjclark@alum.mit.edu
Cc:        Robert Watson <rwatson@FreeBSD.ORG>, "Brian F. Feldman" <green@FreeBSD.ORG>, Peter Pentchev <roam@orbitel.bg>, achilov@granch.ru, Przemyslaw Frasunek <venglin@freebsd.lublin.pl>, freebsd-security@FreeBSD.ORG
Subject:   Re: ncurses buffer overflows (fwd)
Message-ID:  <20001011080628.F387D1F22@static.unixfreak.org>
In-Reply-To: <20001010214332.G25121@149.211.6.64.reflexcom.com> "from Crist J . Clark at Oct 10, 2000 09:43:32 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <dima@unixfreak.org>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001011080628.F387D1F22>