Re: SHELLOPTS=xtrace security hardening

[Stephane Chazelas]

2015-12-10 20:16:49 +0100, up201407890@alunos.dcc.fc.up.pt:
> Hello,
> 
> This is a suggestion for a bash security hardening patch which
> prevents xtrace from being initialized to the SHELLOPTS environment
> variable when a new shell starts.
> 
> xtrace can be used to exploit bogus system()/popen() calls on setuid
> binaries via a specially crafted PS4 environment variable leading to
> privilege escalation, like so:
> 
> 
> # gcc -xc - -otest <<< 'int main() { setuid(0); system("/bin/date"); }'
> # chmod 4755 ./test
> # ls -l ./test
> -rwsr-xr-x. 1 root root 8549 Dec 10 18:06 ./test
> # exit
> $ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
> uid=0(root)
> Thu Dec 10 18:06:36 WET 2015
> 
> 
> This means, that setuid programs which call system(3)/popen(3) (a
> horrendously bad practice in any case) are vulnerable, since it's
> safe to assume that most of these do not ignore such environment
> variables.
[...]

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.

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.

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.

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.

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.

-- 
Stephane