Re: unable to attach to setuid program that as reverted it privilege

Re: unable to attach to setuid program that as reverted it privilege

[Reynolds, Brandon]

I can't seem to get this to work.

I have a setuid executable with the following code:
-----------------------------------------------------------------------------
    /* keep root capabilities as we transition to the regular user */
    prctl( PR_SET_KEEPCAPS, 1, 0, 0, 0 );

    /* switch back to user that ran us */
    setuid( p->pw_uid );
    setgid( p->pw_gid );

    /* drop all privs except CAP_SYS_NICE */
    if (cap_set_proc((cap = cap_from_text( "CAP_SYS_NICE+pe" ))) < 0)
    {
        perror( "cap_set_proc: failed to drop privs, aborting" );
        exit( 1 );
    }
    cap_free(cap);
-----------------------------------------------------------------------------

> cat /proc/sys/kernel/suid_dumpable
2

> uname -a
Linux sgi2 2.6.16.46-0.12-default #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64 GNU/Linux

FYI, the man 5 proc says:

/proc/sys/fs/suid_dumpable (since Linux 2.6.13)
              The value in this file determines whether core dump files are produced for set-user-ID or otherâ
              wise protected/tainted binaries.  Three different integer values can be specified:

              0 (default) This provides the traditional (pre-Linux 2.6.13) behaviour.  A core dump will not be
              produced for a process which has changed credentials (by calling seteuid(2), setgid(2), or simiâ
              lar,  or  by executing a set-user-ID or set-group-ID program) or whose binary does not have read
              permission enabled.

              1 ("debug") All processes dump core when possible.  The core dump is owned by  the  file  system
              user  ID  of the dumping process and no security is applied.  This is intended for system debugâ
              ging situations only.  Ptrace is unchecked.

              2 ("suidsafe") Any binary which normally would not be dumped (see "0" above) is dumped  readable
              by  root only.  This allows the user to remove the core dump file but not to read it.  For secuâ
              rity reasons core dumps in this mode will not overwrite one another or other files.   This  mode
              is appropriate when administrators are attempting to debug problems in a normal environment.

> This is documented as allowing core files to be created for setuid
> programs.  What I am using it for is to allow gdb run as a non-root
> user to connect to setuid programs that have _permanently_ given up
> their root privilege.  Without suid_dumpable enabled, gdb will fail
> with a EPERM error even tho the target program is no longer running as
> root and can not reacquire root privilege ( a good default behavior ).

What did you mean by "_permanently_"?

-Brandon

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

On Mon, Apr 14, 2008 at 8:32 AM, Reynolds, Brandon
<brandon.reynolds@lmco.com> wrote:
>
>
>  What did you mean by "_permanently_"?
>

I used setuid(non_root_user) while the effective user is root.  This
sets real, effective, and saved userids so that there is no returning
to root.

I confirm that in my code by doing a setuid(root) and hoping that it fails.

-- 
Michael Potter

Re: unable to attach to setuid program that as reverted it privilege

[Tavis Ormandy]

On Mon, Apr 14, 2008 at 09:32:34AM -0400, Reynolds, Brandon wrote:
> > This is documented as allowing core files to be created for setuid
> > programs.  What I am using it for is to allow gdb run as a non-root
> > user to connect to setuid programs that have _permanently_ given up
> > their root privilege.  Without suid_dumpable enabled, gdb will fail
> > with a EPERM error even tho the target program is no longer running as
> > root and can not reacquire root privilege ( a good default behavior ).
> 

Consider the suid root ping program, it aquires a SOCK_RAW socket, and
then drops privileges. If you were allowed to attach to it after it has
dropped privileges, you could wait for it to get the socket, then
PTRACE_ATTACH and PTRACE_POKE in your own code, which now has a raw
socket that it can use for any purpose it likes.

Obviously, this cannot be permitted (i'm sure some operating systems get
it wrong though :-)).

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

RE: unable to attach to setuid program that as reverted it privilege

[Reynolds, Brandon]

Tavis,

Obviously there are security risks involved; however, sometimes the
choice is between giving users root and allowing them to debug a process
with some extended capabilities.

Michael,

I agree wholeheartedly with you that it would be good to have some fine
grained control over things.  I wonder if that is what
prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) is supposed to do?  See "man 2 prctl"
for details.

I can't seem to reproduce results however with either tweaking the proc
file or calling prctl().  What kernel are you running?

-Brandon

-----Original Message-----
From: Tavis Ormandy [mailto:taviso@sdf.lonestar.org] 
Sent: Monday, April 14, 2008 9:46 AM
To: Reynolds, Brandon
Cc: pottmi@gmail.com; gdb@sourceware.org
Subject: Re: unable to attach to setuid program that as reverted it
privilege

On Mon, Apr 14, 2008 at 09:32:34AM -0400, Reynolds, Brandon wrote:
> > This is documented as allowing core files to be created for setuid
> > programs.  What I am using it for is to allow gdb run as a non-root
> > user to connect to setuid programs that have _permanently_ given up
> > their root privilege.  Without suid_dumpable enabled, gdb will fail
> > with a EPERM error even tho the target program is no longer running
as
> > root and can not reacquire root privilege ( a good default behavior
).
> 

Consider the suid root ping program, it aquires a SOCK_RAW socket, and
then drops privileges. If you were allowed to attach to it after it has
dropped privileges, you could wait for it to get the socket, then
PTRACE_ATTACH and PTRACE_POKE in your own code, which now has a raw
socket that it can use for any purpose it likes.

Obviously, this cannot be permitted (i'm sure some operating systems get
it wrong though :-)).

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

On Mon, Apr 14, 2008 at 11:28 AM, Reynolds, Brandon
<brandon.reynolds@lmco.com> wrote:
> Tavis,
>
>  Obviously there are security risks involved; however, sometimes the
>  choice is between giving users root and allowing them to debug a process
>  with some extended capabilities.
>
>  Michael,
>
>  I agree wholeheartedly with you that it would be good to have some fine
>  grained control over things.  I wonder if that is what
>  prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) is supposed to do?  See "man 2 prctl"
>  for details.
>
>  I can't seem to reproduce results however with either tweaking the proc
>  file or calling prctl().  What kernel are you running?
>

I am using what ever kernel is default with opensuse 10.3.  Sorry, I
am not at my suse box right now to give you a definite answer.

I played with prctl some time ago to fix a similar problem.  I did not
have any luck.  I kept running into people telling me that I should
not do that because it is a security hole.

If I recall correctly (and this was a couple of years ago), I looked
at the kernel source for pattach and found that the EPERM error was
output regardless of the process control or capability settings.  My
conclusion at that time was that it not implemented.

-- 
Michael Potter

unable to attach to setuid program that as reverted it privilege

[Michael Potter]

Gdb Crew,

I get this error when attaching to a setuid program that has
_given_up_ its root privilege setuid(getuid()):

---------------------
x~> gdb -p 19484
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-suse-linux".
Attaching to process 19484
ptrace: Operation not permitted.            <<<<<=================

--------------------
I will speculate that the logic behind that is even tho the program
does not have root privilege now, it could have something in left over
in memory from when it did have root privilege.  I think this is a
good default behavior, but I am hopeful that some clever programmer
has found a way to change their program such that gdb can attach to
it.

My program _only_ uses root privilege to be able to be able to do a
oneway switch to a non-privileged user.  I believe that any hole I am
opening up is much smaller than my next alternative which is to allow
the programmers to run gdb as root so they can attach to the program.

Suggestions on alternatives such as a way to switch users without root
privileges
are welcome.

Thanks,

For those of you who may want to reproduce this feature here are some
cut and paste ready instructions:
1) mkdir -p tmp/setuidtest;cd tmp/setuidtest
2) vim iamsetuidroot.c   # paste in the following:
#include <stdio.h>
#include <stdlib.h>

int main(int arc, char *argv[])
{
   if (geteuid() != 0)
   {
      printf("this program must be run setuid root, not %d\n",
geteuid());
      exit(1);
   }
   if (getuid() == 0)
   {
      printf("this program must not be run as root\n");
      exit(1);
   }

   setuid(getuid());

   if (!setuid(0))
   {
      /* we want setuid to fail to be able to return to root */
      printf("this program was able to revert to root\n");
      exit(1);
   }

   printf("before the sleep %d\n", getpid());

   sleep(60);

   printf("after the sleep\n");

   exit(0);

}

3) cc -o iamsetuidroot iamsetuidroot.c
4) sudo chown root iamsetuidroot
5) sudo chmod u+s iamsetuidroot
6) ./iamsetuidroot   # observe pid in output.
7) gdb -p $thePid    # in another window

Re: unable to attach to setuid program that as reverted it privilege

[Daniel Jacobowitz]

On Tue, Jan 22, 2008 at 01:59:48PM -0600, Michael Potter wrote:
> I will speculate that the logic behind that is even tho the program
> does not have root privilege now, it could have something in left over
> in memory from when it did have root privilege.  I think this is a

Correct.  For instance, it could have an open file descriptor to a
root-owned file or a privileged network socket.  There's lots of
things you can inherit.

> good default behavior, but I am hopeful that some clever programmer
> has found a way to change their program such that gdb can attach to
> it.

It has nothing to do with the program; this is part of your kernel's
security model.  Sorry.  I believe it's pretty much universal behavior
across Unix-like systems.

> Suggestions on alternatives such as a way to switch users without root
> privileges
> are welcome.

Allow "sudo -u otheruser ./nonsetuid-copy-of-program" ?

-- 
Daniel Jacobowitz
CodeSourcery

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

On Jan 22, 2008 2:08 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Jan 22, 2008 at 01:59:48PM -0600, Michael Potter wrote:
> > I will speculate that the logic behind that is even tho the program
> > does not have root privilege now, it could have something in left over
> > in memory from when it did have root privilege.  I think this is a
>
> Correct.  For instance, it could have an open file descriptor to a
> root-owned file or a privileged network socket.  There's lots of
> things you can inherit.
>
> > good default behavior, but I am hopeful that some clever programmer
> > has found a way to change their program such that gdb can attach to
> > it.
>
> It has nothing to do with the program; this is part of your kernel's
> security model.  Sorry.  I believe it's pretty much universal behavior
> across Unix-like systems.
>
> > Suggestions on alternatives such as a way to switch users without root
> > privileges
> > are welcome.
>
> Allow "sudo -u otheruser ./nonsetuid-copy-of-program" ?
>

My program is a daemon process that runs as root.
When it starts is reduces it's privilege and it returns its privilege
to just long enough to validate the user's password.
It then forks.  The child returns its root priv  to do the one way
switch to the new user.

The reason I think someone may have a solution to this (even if it is
a hack) is that exec will solve the problem.  I do not want to add an
exec to my code because I do not want the overhead of exec.

I am thinking that someone may have written a loadable kernel module
that would be tweak the same bit that exec tweaks that would allow the
connect.  That module would be called by the program.

> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: unable to attach to setuid program that as reverted it privilege

[Mark Kettenis]

> Date: Tue, 22 Jan 2008 13:59:48 -0600
> From: "Michael Potter" <pottmi@gmail.com>
> 
> Gdb Crew,
> 
> I get this error when attaching to a setuid program that has
> _given_up_ its root privilege setuid(getuid()):
> 
> ---------------------
> x~> gdb -p 19484
> GNU gdb 6.5
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i586-suse-linux".
> Attaching to process 19484
> ptrace: Operation not permitted.            <<<<<=================

This is the only acceptable behaviour.  The program might have dropped
root priviliges but it might still hold resources acquired when it
still had those priviliges and you might be able to exploit those.

You should be able to attach to the process as root.  If not, complain
to the Linux kernel people.

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

On Jan 23, 2008 11:52 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > Date: Tue, 22 Jan 2008 13:59:48 -0600
> > From: "Michael Potter" <pottmi@gmail.com>
> >
> > Gdb Crew,
> >
> > I get this error when attaching to a setuid program that has
> > _given_up_ its root privilege setuid(getuid()):
> >
> > ---------------------
> > x~> gdb -p 19484
> > GNU gdb 6.5
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "i586-suse-linux".
> > Attaching to process 19484
> > ptrace: Operation not permitted.            <<<<<=================
>
> This is the only acceptable behaviour.  The program might have dropped
> root priviliges but it might still hold resources acquired when it
> still had those priviliges and you might be able to exploit those.
>
> You should be able to attach to the process as root.  If not, complain
> to the Linux kernel people.
>
>

You are my point for me.
I really really really do not want to give me programmers the ability
to run the debugger as root.

I think disallowing the attach is the only acceptable _default_
behavior; but I think I should be able to override that default when I
am confident that my program does not hold any privileged resources.

I will post to a Linux kernel list in a couple of days.  I posted here
because I felt that I was likely to find someone who had the same
problem in this group.

If I have to allow the programmers to run the debugger as root I will
have to wrap it in a script that will prevent them from attaching to
any other process than the ones that I can programmaticaly identify as
ok.  Is there any option on gcc that will disable gcc commands that
might be used to attach to other processes once they have started gcc
as root?

Thanks all for your thoughtful replies.

-- 
Michael Potter

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

On Jan 23, 2008 12:48 PM, Michael Potter <pottmi@gmail.com> wrote:
>
> On Jan 23, 2008 11:52 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > Date: Tue, 22 Jan 2008 13:59:48 -0600
> > > From: "Michael Potter" <pottmi@gmail.com>
> > >
> > > Gdb Crew,
> > >
> > > I get this error when attaching to a setuid program that has
> > > _given_up_ its root privilege setuid(getuid()):
> > >
> > > ---------------------
> > > x~> gdb -p 19484
> > > GNU gdb 6.5
> > > Copyright (C) 2006 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public License, and
> > > you are
> > > welcome to change it and/or distribute copies of it under certain
> > > conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB.  Type "show warranty" for
> > > details.
> > > This GDB was configured as "i586-suse-linux".
> > > Attaching to process 19484
> > > ptrace: Operation not permitted.            <<<<<=================
> >
> > This is the only acceptable behaviour.  The program might have dropped
> > root priviliges but it might still hold resources acquired when it
> > still had those priviliges and you might be able to exploit those.
> >
> > You should be able to attach to the process as root.  If not, complain
> > to the Linux kernel people.
> >
> >
>
> You are my point for me.
> I really really really do not want to give me programmers the ability
> to run the debugger as root.
>
> I think disallowing the attach is the only acceptable _default_
> behavior; but I think I should be able to override that default when I
> am confident that my program does not hold any privileged resources.
>
> I will post to a Linux kernel list in a couple of days.  I posted here
> because I felt that I was likely to find someone who had the same
> problem in this group.
>
> If I have to allow the programmers to run the debugger as root I will
> have to wrap it in a script that will prevent them from attaching to
> any other process than the ones that I can programmaticaly identify as
> ok.  Is there any option on gcc that will disable gcc commands that
> might be used to attach to other processes once they have started gcc
> as root?

oops, my brain was thinking gdb, my fingers typed gcc.

>
> Thanks all for your thoughtful replies.
>
> --
> Michael Potter
>

Re: unable to attach to setuid program that as reverted it privilege

[Andreas Schwab]

"Michael Potter" <pottmi@gmail.com> writes:

> I will post to a Linux kernel list in a couple of days.  I posted here
> because I felt that I was likely to find someone who had the same
> problem in this group.

/proc/sys/kernel/suid_dumpable might be what you are looking for.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: unable to attach to setuid program that as reverted it privilege

[Michael Potter]

Andreas,

works great.

Here are a few notes in case someone else has this same problem....

To turn this on, do this:
1) log in as root
2) echo 2 >/proc/sys/kernel/suid_dumpable

To turn this off, do this:
1) log in as root
2) echo 0 >/proc/sys/kernel/suid_dumpable

On some systems the target file might be in /proc/sys/fs

It will not work to just use sudo in front of echo.  You must log in
as root because the redirection has the user's privilege.

I do not know what echo 1 would do.

This is documented as allowing core files to be created for setuid
programs.  What I am using it for is to allow gdb run as a non-root
user to connect to setuid programs that have _permanently_ given up
their root privilege.  Without suid_dumpable enabled, gdb will fail
with a EPERM error even tho the target program is no longer running as
root and can not reacquire root privilege ( a good default behavior ).

This will work fine for my needs, but I would prefer finer grained control.
that is:
1) separate attaching and core dumping.
2) don't turn on this feature for _all_ processes, just select processes.

This should only be used in a controlled environment because of the
security issues.

Because this turns on core dumping it would be prudent to also look
into /proc/sys/kernel/core_pattern to prevent name collision when core
dumps are created.

-- 
Michael Potter

On Jan 23, 2008 2:42 PM, Andreas Schwab <schwab@suse.de> wrote:
> "Michael Potter" <pottmi@gmail.com> writes:
>
> > I will post to a Linux kernel list in a couple of days.  I posted here
> > because I felt that I was likely to find someone who had the same
> > problem in this group.
>
> /proc/sys/kernel/suid_dumpable might be what you are looking for.
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

Re: unable to attach to setuid program that as reverted it privilege

[Andreas Schwab]

"Michael Potter" <pottmi@gmail.com> writes:

> It will not work to just use sudo in front of echo.

The redirection must of course be performed as root.

$ sudo sh -c 'echo 2 > /proc/sys/kernel/suid_dumpable'

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."