Re: SHELLOPTS=xtrace security hardening

[up201407890]

Quoting "Chet Ramey" <chet.ramey@case.edu>:

> On 12/10/15 2:16 PM, up201407890@alunos.dcc.fc.up.pt wrote:
> > 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.
>
> This is far too drastic a solution to the problem you have posed.
>
> > 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:
>
> I don't really see privilege escalation here.  Your setuid root program
> sets the real and effective UIDs to 0 and calls system().  There is no
> way to distinguish this as the result of running a setuid program, and
> any privilege escalation takes place before system() runs.

Yes, privilege escalation happens before system(), but it is possible  
to run arbitrary commands as uid 0.

> I have to tell you, if I wanted to exploit a program written this poorly,
> I wouldn't mess around with SHELLOPTS.  I'd go straight to PATH.

The test case I presented couldn't be abused by PATH because i gave it  
a full path, as in system("/bin/date")

Here's another example:

# cat test.c
int main()
{
        putenv("PATH=/bin:/usr/bin");
        setuid(0);
        system("/bin/date");
}
# gcc test.c
# chmod 4755 a.out
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./a.out
uid=0(root)
Sun Dec 13 19:35:14 WET 2015

As horrible as it is to setuid() and system(), this wouldn't seem like  
a vulnerable program.

AFAIK, privmode has made it into bash to defend against these poorly  
written programs, as seen in section 7 of the bash NOTES file.
http://tiswww.case.edu/php/chet/bash/NOTES

So, in upstream bash, if uid != euid it drops privileges.
This means that if someone really wants to change privileges in a  
setuid binary, he just needs to take an extra step and add  
setuid()/setreuid() in there. After that, they'd be equally as  
vulnerable. Obviously bash does more than it's asked by using such  
functionality, which some other shells don't.
Only recently dash started adopting it.
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/comments/6

> This isn't a good reason to take xtrace out of $SHELLOPTS unconditionally.
> It's not even a good enough reason to ignore SHELLOPTS if the shell is
> running as uid 0.

This doesn't completely remove it.

For example, bash -x would still work:

$ cat test.sh
#!/bin/bash

printf 'Hello Chet\n'
echo $SHELLOPTS
$ bash -x test.sh
+ printf 'Hello Chet\n'
Hello Chet
+ echo braceexpand:hashall:interactive-comments:xtrace
braceexpand:hashall:interactive-comments:xtrace


Only problem would be, as Stephane said, when other programs invoke  
shell scripts.

Maybe another way of solving this problem would be initializing $PS4  
with it's default value "+ ", and not importing it from the environment.
I believe that would be a much better solution.



$ diff -Naur bash-4.2.53 bash-4.2.53.patch/
diff -Naur bash-4.2.53/variables.c bash-4.2.53.patch/variables.c
--- bash-4.2.53/variables.c     2014-10-01 20:54:55.000000000 +0100
+++ bash-4.2.53.patch/variables.c       2015-12-13 21:51:38.926476398 +0000
@@ -465,7 +465,10 @@
 #endif
       set_if_not ("PS2", secondary_prompt);
     }
-  set_if_not ("PS4", "+ ");
+  /* Don't allow PS4 to be imported from the environment.
+     Specially crafted SHELLOPTS+PS4 could be used to exploit
+     bogus system(3)/popen(3) calls in setuid executables. */
+  bind_variable ("PS4", "+ ", 0);

   /* Don't allow IFS to be imported from the environment. */
   temp_var = bind_variable ("IFS", " \t\n", 0);



# rm /bin/bash
# cp ./bash /bin/bash
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./a.out
+ /bin/date
Sun Dec 13 21:56:38 WET 2015


Thoughts on this?


Thanks,
Federico Bento.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



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