security risk in source builtin?

security risk in source builtin?

[Dominik Vogt]

A colleague and I just noticed that the "source" builtin looks for
its argument in the $PATH.  I guess that's something POSIX
demands, but isn't it also a security risk?  In this case, the
following happened:

  $ ls -F
  test
  $ cat test
  echo hello world
  $ source test
  /usr/bin/test:3: bad pattern: ^@^F^@(...

Unless it is really important to have this behaviour for
compatibility reasons, shouldn't searching the $PATH be at least
disabled by default?

Ciao

Dominik ^_^  ^_^

Re: security risk in source builtin?

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

Dominik Vogt wrote [2003/09/17]:
> A colleague and I just noticed that the "source" builtin looks for
> its argument in the $PATH.  I guess that's something POSIX
> demands, but isn't it also a security risk?  In this case, the
> following happened:
> 
>   $ ls -F
>   test
>   $ cat test
>   echo hello world
>   $ source test
>   /usr/bin/test:3: bad pattern: ^@^F^@(...

Are you really sure you typed "source" here?

> Unless it is really important to have this behaviour for
> compatibility reasons, shouldn't searching the $PATH be at least
> disabled by default?

Quoting the manpage:

       source file [ arg ... ]
              Same  as ., except that the current directory is always searched
              and is always searched first, before directo- ries in $path.

Testing myself:
    /tmp> cat test
    echo hello world
    /tmp> ls -l test
    -rw-r--r--    1 jean-luc jean-luc       17 2003-09-17 08:49 test
    /tmp> . test
    /usr/bin/test:12: parse error near `)'
    /tmp> source test
    hello world

Seems you have typed ". test" :-)

       . file [ arg ... ]
              Read commands from file and execute them in the
              current shell environment.

              If file does not contain a slash, or if PATH_DIRS
              is set, the shell looks in the components of $path
              to  find the  directory  containing  file.  Files
              in the current directory are not read unless `.'
              appears somewhere in $path.  If a file named
              `file.zwc' is found, is newer than file, and is the
              compiled form  (created  with  the zcompile
              builtin) of file, then commands are read from that
              file instead of file.

              If  any  arguments  arg  are  given,  they become
              the positional parameters; the old positional
              parameters are restored when the file is done
              executing.  The exit status is the exit status of
              the last command executed.


> Ciao
> 
> Dominik ^_^  ^_^

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: security risk in source builtin?

[Dominik Vogt]

On Wed, Sep 17, 2003 at 08:58:02AM +0200, Thomas Köhler wrote:
> Dominik Vogt wrote [2003/09/17]:
> > A colleague and I just noticed that the "source" builtin looks for
> > its argument in the $PATH.  I guess that's something POSIX
> > demands, but isn't it also a security risk?  In this case, the
> > following happened:
> > 
> >   $ ls -F
> >   test
> >   $ cat test
> >   echo hello world
> >   $ source test
> >   /usr/bin/test:3: bad pattern: ^@^F^@(...
> 
> Are you really sure you typed "source" here?

I may have confused the test cases for bash and zsh.  Thanks for
pointing that out.  However, that does not change my concern that
"source" (as well as ".") is a security risk.

> > Unless it is really important to have this behaviour for
> > compatibility reasons, shouldn't searching the $PATH be at least
> > disabled by default?
> 
> Quoting the manpage:
> 
>        source file [ arg ... ]
>               Same  as ., except that the current directory is always searched
>               and is always searched first, before directo- ries in $path.
> 
> Testing myself:
>     /tmp> cat test
>     echo hello world
>     /tmp> ls -l test
>     -rw-r--r--    1 jean-luc jean-luc       17 2003-09-17 08:49 test
>     /tmp> . test
>     /usr/bin/test:12: parse error near `)'
>     /tmp> source test
>     hello world
> 
> Seems you have typed ". test" :-)
> 
>        . file [ arg ... ]
>               Read commands from file and execute them in the
>               current shell environment.
> 
>               If file does not contain a slash, or if PATH_DIRS
>               is set, the shell looks in the components of $path
>               to  find the  directory  containing  file.  Files
>               in the current directory are not read unless `.'
>               appears somewhere in $path.  If a file named
>               `file.zwc' is found, is newer than file, and is the
>               compiled form  (created  with  the zcompile
>               builtin) of file, then commands are read from that
>               file instead of file.
> 
>               If  any  arguments  arg  are  given,  they become
>               the positional parameters; the old positional
>               parameters are restored when the file is done
>               executing.  The exit status is the exit status of
>               the last command executed.

Ciao

Dominik ^_^  ^_^

Re: security risk in source builtin?

[Dominik Vogt]

On Wed, Sep 17, 2003 at 06:24:20PM +0800, James Devenish wrote:
> In message <20030916145820.GC4583@gmx.de>
> on Tue, Sep 16, 2003 at 04:58:20PM +0200, Dominik Vogt wrote:
> > but isn't it also a security risk?  In this case, the
> > following happened:
> > 
> >   $ ls -F
> >   test
> >   $ cat test
> >   echo hello world
> >   $ source test
> >   /usr/bin/test:3: bad pattern: ^@^F^@(...
 
> Could you please explain to me how this is a security risk? Are you
> merely trying to say that is offers the possibility of the wrong command
> being executed, or are you saying it could lead to some exploitable
> condition such as execution of a file that could not normally be
> executed?

To the casual user, it is not obvious why the $PATH should be
searched.  After all, scripts read with "source" or "." should
usually not be executable, so they do not belong into any
directory in the $PATH.  On the other hand scripts in the $PATH
normally begin with "#!<path to parser>" and should never be read
with "source" or "." (it's not guaranteed that the "#" character
introduces a comment).

This is not a vulnenrability per se and is not exploitable unless
the user makes an additional mistake (like using "." in the PATH).

The security risk here is that it is by no means obvious that or
why the $PATH is searched for the script.  At the very least, I
think "source" and "." should not attempt to read files in the
$PATH that are not executable.  Of course this is only my mersonal
opinion

> How is this different to simply feeding arbitrary bytes to the
> command line with your terminal or pipe?

Only in the way it is invoked.

P.S.:  I'm now subscribed to the mailing list.  It's not necessary
to answer to me personally.

Ciao

Dominik ^_^  ^_^

Re: security risk in source builtin?

[James Devenish]

In message <20030917110731.GA535@gmx.de>
on Wed, Sep 17, 2003 at 01:07:31PM +0200, Dominik Vogt wrote:
> > >   $ source test
> > >   /usr/bin/test:3: bad pattern: ^@^F^@(...
[...]
> To the casual user, it is not obvious why the $PATH should be
> searched.  After all, scripts read with "source" or "." should
> usually not be executable, so they do not belong into any
> directory in the $PATH.
[...]
> At the very least, I
> think "source" and "." should not attempt to read files in the
> $PATH that are not executable.  Of course this is only my mersonal

As you mentioned, the . command is provided by the POSIX shell. I would
expect that changing its behaviour would cause existing scripts to fail,
as well as affecting portability. I think that it is bad to be scripting
with ". test" if you desire the semantics of ". ./test" (in the case
that you use "./test", $path will not be searched). You are right that
it is a "trap" to fall into, but there is a definite difference between
". test" and ". ./test" and it is probably more important that authors
code carefully (as always applies to coding).

Re: security risk in source builtin?

[Phil Pennock]

On 2003-09-17 at 09:35 +0200, Dominik Vogt wrote:
> I may have confused the test cases for bash and zsh.  Thanks for
> pointing that out.  However, that does not change my concern that
> "source" (as well as ".") is a security risk.

Could you please explain how it's a security risk?  I think I'm missing
something.

My viewpoint is based around the idea that when I type a command-name,
a process is started running from a program stored somewhere in $PATH,
and runs with all my access rights.  So if someone untrusted can write
to somewhere in $PATH then execlp()/execvp() become dangerous and most
of Unix suddenly has security holes.

Don't add directories to $PATH unless you absolutely trust everyone who
can write to that directory, or move it aside somewhere up the
filesystem tree, or can write to a file in that directory.

Hence the presence of "." as an element of $PATH (or the equivalent
empty element, indicated by double, leading or trailing colons) is a
very dubious practice.  And using "source" is dubious, unless you're
very sure of where you are.

I've trained myself to use ". ./filename" so that at least it's explicit
that I know that it's the current directory.

Now, if the modern ACL and MAC unices have a way for executables to
inherit privilege-dropping flags from a directory, so that a directory
can be flagged so that all executables within it automatically revoke
some set of privileges, _then_ having "source"/"." use the same $PATH
becomes an issue.  But AFAIK, none of the systems about support this
sort of inheritance of extended attributes (I could well be wrong).
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: security risk in source builtin?

[Dominik Vogt]

On Wed, Sep 17, 2003 at 07:48:53PM +0800, James Devenish wrote:
> In message <20030917110731.GA535@gmx.de>
> on Wed, Sep 17, 2003 at 01:07:31PM +0200, Dominik Vogt wrote:
> > > >   $ source test
> > > >   /usr/bin/test:3: bad pattern: ^@^F^@(...
> [...]
> > To the casual user, it is not obvious why the $PATH should be
> > searched.  After all, scripts read with "source" or "." should
> > usually not be executable, so they do not belong into any
> > directory in the $PATH.
> [...]
> > At the very least, I
> > think "source" and "." should not attempt to read files in the
> > $PATH that are not executable.  Of course this is only my mersonal
> 
> As you mentioned, the . command is provided by the POSIX shell. I would
> expect that changing its behaviour would cause existing scripts to fail,
> as well as affecting portability. I think that it is bad to be scripting
> with ". test" if you desire the semantics of ". ./test" (in the case
> that you use "./test", $path will not be searched). You are right that
> it is a "trap" to fall into, but there is a definite difference between
> ". test" and ". ./test" and it is probably more important that authors
> code carefully (as always applies to coding).

Okay, this is what POSIX says for ".":

  If file does not contain a slash, the shell shall use the search
  path specified by PATH to find the directory containing file.
  Unlike normal command search, however, the file searched for by
  the dot utility need not be executable.

which is implemented correctly in zsh, but not in bash (who cares
;-) ) or pdksh.  I.e. zsh looks in the $PATH only while bash tries
. if $PATH fails.  "source" is not part of POSIX.  So it seems the
security problem is in the POSIX spec itself :-P

Ciao

Dominik ^_^  ^_^