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.