suid root - bash script

[Yedidyah Bar-David]

Hi Noam,

On Thu, Apr 23, 2009 at 12:08:21PM +0300, Noam Rathaus wrote:
> Hi Yedidyah,
> 
> This "stupid" - in my opinion - restriction also applies to perl script.

This is a free country, you know. You are entitled have your own
opinion. As I exaplained below, the main problem with setuid scripts is
irrespective of interpreter, be it /bin/sh, perl, or your own binary for
whatever language you invented.

> 
> And there they also recommend using a C program that will be setuid
> that will run the  perl script.

Indeed. Or use sudo (which is the same, only general).

> 
> This is of course an over-complicated manner of doing things,

I guess there are other ways to do this, but that's how it is in unix.
As far as I know, Windows does not have something similar at all - if
you want there to run some program as another user, you have to do much
more than setuid it.

> not to
> mention the fact that if this perl script or c program wrapper is then
> called from Apache the restriction still applies and I haven't been
> able to get around it.

I did not understand what exact restriction you talk about, what you
tried to achieve and what was the problem. If you want anyone to try and
help you, please provide some more details.

Best,
-- 
Didi

> On Thu, Apr 23, 2009 at 11:54 AM, Yedidyah Bar-David
> <linux-il at didi.bardavid.org> wrote:
> > On Thu, Apr 23, 2009 at 11:31:38AM +0300, 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?
> >
> > The main famous one, inherent in the way scripts work, is that the
> > kernel has to look at the first line of the script, run the interpreter
> > mentioned there with the args provided, and this interpreter then runs,
> > looks at the script, and decides what to do. Running the interpreter
> > takes time, and so an attacker can make a symlink to it, run the
> > symlink, and replace it immediately, and have a chance to make the
> > interpreter run the attacker's version instead of the original. This is
> > different from running a binary directly, where the kernel knows where
> > it was and won't have to look again if you tried replacing a symlink to
> > it.
> >
> >>>
> >>> 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.
> >>
> >> 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.
> >
> > Well, I now googled for 'setuid scripts security' and found this FAQ:
> > http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html
> > It also mentions other, more-specific issues.
> >
> >> 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.
> >
> > Indeed, but there are some differences - usually, finding bugs in
> > scripts is easier (especially if you do not have the sources for the
> > C-coded binary), and in the past there used to be bugs in various
> > interpreters of various OSes. The last point is hopefully less relevant
> > today, but so are setuid-scripts (I think no modern unix respects
> > these).
> >
> >>
> >> So my question is: are there attack vectors against the following script?
> >>
> >> #!/bin/sh -e
> >>
> >> echo "Hello, cruel world"
> > --
> > Didi
> >
> >
> > _______________________________________________
> > Linux-il mailing list
> > Linux-il at cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> >
> >