Re: CDPATH and shell scripts
Hi:
There are lots of variables which do nasty things.
In particular (copying this from perldoc of a module I wrote):
PATH
PATH provides a list of paths to search for executables, which
influences which commands are invoked by unqualified calls to system()
and others. This variable is particularly dangerous because even if
you use a fully qualified call to the executable, like "/usr/bin/echo
..." -- there is still a security hole, since echo could be executing
unqualified code itself.
The safest way to handle this, and the strategy used by this module,
is to remove everything except /usr/bin and /usr/local/bin (or
equivalent, depending on your operating system).
CDPATH
CDPATH provides additional paths for cd to search on the system when
it is called. This is dangerous because you could be attempting to
change into a known safe directory, but the CDPATH may divert you to
another directory. The variable is generally of limited usefulness,
and so is removed completely during %ENV scrubbing.
IFS
IFS is the Internal Field Separator, which tells the operating system
what characters should be considered whitespace separating command
line arguments. Combined with controlling PATH, this exposes a very
dangerous vulnerability: if the IFS is set to '/', then
system('/bin/more') is essentially the same as system('bin more'). As
a result, the 'bin' command is executed instead of '/bin/more' as
expected.
ENV and BASH_ENV
ENV and BASH_ENV list files that are executed whenever a new shell is
started, which includes whenever a shell script (.sh) is run.
Okay. So what? These issues have existed for a long time.
How to fix them? Write Perl scripts, and turn on taint checking --
that fixes the four issues above, because it makes the script exit if
any of them look dangerous. Env::Sanctify::Auto is a Perl module that
automatically cleans up the paths.
My advice:
1. Write scripts that might be run as root (or setuid root) using Perl
2. Turn on taint checking
3. Consider using Env::Sanctify::Auto (shameless plug)
Cheers,
Jonathan
On Thu, Jul 2, 2009 at 4:22 PM, Michael Tautschnig<mt@debian.org> wrote:
> [...]
>> So what is the right course of action here?
>>
>> 1) unset CDPATH in every single shell script there is?
>> 2) never use relartive paths for cd in scripts?
>> 3) shoot the user for doing something dumb?
>> 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
>> scripts (would break automake I think)
>>
>
> Looking at some autoconf-generated configure script I've found the following:
>
> --------------------------------------------------------------------------------
> # The HP-UX ksh and POSIX shell print the target directory to stdout
> # if CDPATH is set.
> (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
> --------------------------------------------------------------------------------
>
> I had once stumbled over this problem and ever since I keep using
>
> cd bla > /dev/null
>
> whenever the output could possibly trouble me. But well, actually, unsetting
> CDPATH would be more appropriate.
>
> Best,
> Michael
>
>
Reply to: