[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141009061748.GA5352@chaz.gmail.com>
Date: Thu, 9 Oct 2014 07:17:48 +0100
From: Stephane Chazelas <stephane.chazelas@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
2014-10-08 16:05:45 -0700, Michal Zalewski:
> > Well, I guess, but the way you're interpreting this separation of
> > code/data and the way that I am is clearly different.
> > There are clearly cases where separation is practical,
> > non-destructive, and beneficial for security.
>
> Well, in the specific context of bash, where it's being singled out as
> a major contributing factor to the bug: how would you establish an
> out-of-band channel for exporting functions that keeps them separate
> from "pure" data? As far as I can tell, there is no trivial and
> portable way.
[...]
Just to give the discussion a bit more of perspective, here is
some info on how similar things are done in other shells:
In rc (the plan9, Research Unix v10 shell), all functions are
exported in "fn_funcname" variables that are evaluated on the
first call. rc authors considered it was a mistake of the Bourne
shell not to export all its variables to the environment. It
probably made sense for them to say that at the time. In case
you don't know of that shell, rc is the shell with the
cleanest design. It never picked up because it arrived too late
when the Bourne and C shell were predominant (like Plan9 vs
Unix). http://www.in-ulm.de/~mascheck/bourne/unix-faq.shell.rc
http://doc.cat-v.org/plan_9/4th_edition/papers/rc
In the Almquist shell (still in dash and some BSD sh), $PATH
entries that are suffixed with
%func are looked for files with function definitions.
If you have a ~/fun/ls, and PATH=~/fun%func:/bin, and call ls,
~/fun/ls is evaluated and the ls function called instead of the
ls in /bin.
POSIX shells (features comes from ksh) have the ENV variable
which after evaluation (so yes, the parser is invoked on that
variable content) resolves to the path of a file where you can
put function definitions (or anything else). Most shells only do
that when non-interactive though (IIRC that changed because the
feature was abused). bash has BASH_ENV (even for non interactive
shells, but only when invoked as bash, not sh).
You could add a eval "$MY_FUNCTIONS" in there and do export
MY_FUNCTIONS="$(typeset -f myfunctiontoexport)" (I don't know
that it be common practice though).
All csh/tcsh invocations, except when passed the -f option read
the ~/.(t)cshrc. So you could put your alias (csh has no
functions) definitions in there (or source another file
specified in an env var or eval a $MY_ALIASES).
Similarly, zsh has ~/.zshenv (not to be confused with ~/.zshrc),
and $ZDOTDIR to specify where to look for .z*. Again you can
do eval $MY_FUNCTIONS in there.
ksh has $FPATH. like in ash, that's where to look for function
definition files. However, the functions don't take precedence
over commands unless you add an "autoload thefunction" to your
script.
zsh has a similar feature but the "autoload" is always required
and the files are meant to contain the function body (instead of
the full function definition among other things in ash/ksh).
--
Stephane
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
