Re: SHELLOPTS=xtrace security hardening

[up201407890]

Quoting Stephane Chazelas:

> setuid bash will ignore SHELLOPTS (and drop privileges except
> for the patched Debian version). In your case, since you're
> doing a setuid(0), bash is no longer called as setuid, so can't
> detect it.

Correct.

> So you've got a shell started as root with the environment of
> the caller (except for the env vars stripped by the libc),
> SHELLOPTS+PS4 will be an issue, but also TZ (if it's a file
> path, the file will end up being read as root), IFS (not for bash,
> but for dash or posh), PATH, CDPATH, exported functions and all the
> other variables that sudo for instance blacklists.
>
> Doing setuid(0); system(something) is just suicide unless you've
> cleared the whole environment and set only a few necessary env
> vars like sudo does.

I agree. Sadly, some people aren't aware of that.
There have been some trivial vulnerabities like CVE-2013-4011 and  
CVE-2013-1662 that are some-what recent.

> On the other hand,
>
> One of the few things I occasionaly use bash for is for
> SHELLOPTS=xtrace. It is very handy for debugging commands that
> invoke shell scripts. I even end up sometimes replacing /bin/sh
> with bash just for that.
>
> So yes, it would be hardening, but hardening for already broken
> applications and at the expense of a useful feature IMO.

Yes, I understand it may be useful in some cases.

It is because of these broken applications that privileged mode even  
exists in bash in the first place (not Debian's bash). This could  
potentially eliminate almost all system()/popen() vulnerabilities once  
and for all, unless there is a classic ";somecommand", but in that  
case they're just asking for it.

Since doing a setuid(0) bash will no longer be called as setuid, I  
don't think there is another way of stopping this, unless a kernel  
change is made, AFAIK. But that would never happen.


> That's also why I find bash dropping privileges when setuid in
> non-Debian systems a double-edged sword. That means people end
> up doing something a lot worse to work around it.

But if it wasn't for that, most, if not all, setuid binaries that call  
system()/popen() would be vulnerable.

> At least on Debian and all other systems that don't use bash or
> mksh as their sh, if they do system("/some/cmd"), the shell and
> cmd run as root but at least they can now that they are setuid
> so they can enter a restricted mode.

They can, but they never get it right.

Cheers,
Federico Bento.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.