Re: [Sbcl-devel] empty default Unix environment for RUN-PROGRAM: reasonable?

[William H. N. <wil...@ai...>]

On Thu, Jan 18, 2001 at 12:52:36PM +0000, Daniel Barlow wrote:
> >From a security standpoint there's an argument for starting new
> programs with known environment contents rather than "whatever the
> parent had".  If 
> 
>  (a) the parent allows its environment to be changed by a user - and
>  in a large Lisp system it's going to be moderately difficult to prove
>  it doesn't (turned *read-eval* off?  everywhere?), and

(I agree with the general thrust of your argument, but I'd quibble
here: If you have *READ-EVAL* on for data which is under the control
of your adversary, your security is gone immediately. The adversary
doesn't need to mess around with the Unix environment.)
 
>  (b) the parent program operates with different privileges from
>  whatever the user would usually have (not necessarily 'root'; it
>  could be some kind of persistent process running as 'httpd' or
>  'nobody', for example), and invokes the child with those same
>  "interesting" privileges,
> 
> there are all kinds of fun environment variables that can be set to
> subvert the child's behaviour
> 
> I'm thinking about things like the telnetd exploit of yesteryear.
> >From memory (I could be wrong) telnetd stripped everything from the
> enviromnent that it thought might be dangerous (reset PATH, IFS to sane
> values, etc) but having been written in the days before dynamic
> loading it didn't know about LD_PRELOAD.  And LD_PRELOAD when set by a
> malicious user can be _very_ dangerous.
> 
> Emptying the environment won't make it impossible for people to code
> up systems with these kinds of holes, but will help it not to be the
> default action. 

That's a valid point, but I think that instead of trying to defend
innocents who wander into the wild world of setuid security, I'm going
to surrender without a fight. Even in Perl, where setuid security is a
big deal and they've devoted a lot of engineering effort to the
problem (tracking tainted data, etc.) you can still inadvertently make
an insecure script. And there's no way we're going to devote nearly
that much engineering effort to the problem in SBCL.

Besides that, SBCL itself is already a security problem if the
adversary controls the Unix environment, because of the SBCL_HOME
variable.

So I think I will copy the Unix environment by default. However, in
recognition of the long and distinguished history of Unix setuid
security screwups, I'll also put a note in the RUN-PROGRAM doc string,
something like this:
  Running Unix programs from a setuid process, or in any other
  situation where the Unix environment is under the control of someone
  else, is a mother lode of security problems. If you are contemplating
  doing this, read about it first. (The Perl community has a lot of
  good documentation about this and other security issues in script-like
  programs.)

(This is the second time I can remember you pointing out security
issues in SBCL. I'll have to consider your software the next time I
set up a server. It should go well with OpenBSD.:-)

-- 
William Harold Newman <wil...@ai...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C