Security holes, and setuids

Security holes, and setuids

Post by Michael E. Babco » Wed, 07 Jul 1993 00:22:39



Hello, netters, I have some concerns about security that I would like
addressed.

My program is a setuid program (chmod 4755, but not root owned).  

I use the system() call to read and send email.  

Before the system() call I issue a setuid( getuid ) call and after the
system() call I issue a setuid( geteuid ).  This gives me the proper
permissions to allow the reading and sending of email from within the
program and restores the permissions once email has finished.

My questions are:

        Did I open any security holes with this approach?  

        Is there a better way other than setuid( getuid), setuid(
        geteuid ) to accomplish this task?

I am fairly new to UNIX, so any help will be greatly appreciated.

Oh, I am running SunOS 4.1.2 on an IPC system over a network.

Thanks

MB
--

University of Evansville                           - or -
Evansville, IN 47722                     uunet!evansville.edu!babcock
   (812) 423-2733

 
 
 

Security holes, and setuids

Post by Ro » Wed, 07 Jul 1993 02:57:52


The only way your program will run is if you run it as root.
Actually, not even as that since it has the suid flag on, so the
effective user id will be you even if you run it as root.  The problem
is that you are doing setuid(getuid()), and that call should only be
allowed to be used by root... otherwise you can become root by just
saying setuid(0) (and then exec your own shell up).  Some one correct
me if I'm wrong...

Rob
--

Roberto Dorich           |           /~~  \ /  ~~/~~ /~~/  /~~  /|  /    /~~
                         |    SKI   /--    X    /   /__/  /--  / |/ |   /--
Electrical Engineering   |         /__    / \  /   /\    /__  /     |  /__

-------------------------------------------------------------------------------

 
 
 

Security holes, and setuids

Post by Jerry M. Carl » Thu, 08 Jul 1993 06:42:12



Quote:

>Hello, netters, I have some concerns about security that I would like
>addressed.
>My program is a setuid program (chmod 4755, but not root owned)...
>    Did I open any security holes with this approach?  

...

You've opened up the ID that program is owned by. If that ID is 'daemon'
or bin, you've most likely opened up the system (who owns /etc on your
machine, for example).

Attached to this message is a list of items to do when writing setuid
programs.  The list is adapted from:  "How To Write a Setuid Program",
Matt Bishop, ;login:, Vol. 12, No. 1, Jan/Feb, 1987. A longer version is
available:  RIACS TR 85.6, NASA Ames Research Center, Moffett Field, CA
94035. Versions appear in various UNIX security books:

1. Isolate code which needs to be run setuid or setgid in a separate
executable or function when possible.

2. Reset userid and groupid to that of the person running the program as soon
as possible.

3. Be as restrictive as possible in selecting the UID and GID.

4. Reset effective UID and GID and close all unnecessary file descriptors
before calling exec, popen, system and any other command that invokes
another process.

5. Carefully validate any user supplied arguments to exec, system or
popen.

6. Make no assumptions about environment variables. At a minimum, verify
or override PATH, IFS and SHELL. In some versions of UNIX, overriding
environment variables for shared libraries such as LD_LIBRARY_PATH and
LD_PRELOAD on SUN is also necessary.

7. It is not safe to use creat or functions that use creat for locking.

8. Catch ALL signals except SIGKILL and SIGCLD.

9. Check all function returns for errors and abort execution if necessary.

10. Programs interrupted during file creation can leave a file owned by
the effective user rather than the real user. A creat followed by a chown
is not 100% safe.

11. Strip the program and install it with other mode "1" so strings cannot
be used on it.

12. Consider logging program name, real uid, tty and time executed.

--

Alchemical Engineer and Virtual Realist
--

Alchemical Engineer and Virtual Realist

 
 
 

Security holes, and setuids

Post by Nigel Johnst » Thu, 08 Jul 1993 01:17:30



>The only way your program will run is if you run it as root.
>Actually, not even as that since it has the suid flag on, so the
>effective user id will be you even if you run it as root.  The problem
>is that you are doing setuid(getuid()), and that call should only be
>allowed to be used by root... otherwise you can become root by just
>saying setuid(0) (and then exec your own shell up).  Some one correct
>me if I'm wrong...

>Rob
>--

I'd dispute this in that we don't know the application (and because the
original message seems to imply that its working :-).

Given a program thats got suid and is owned by say uucp, then on invocation
the real user id would be the login uid and the effective uid would be uucp,
on calling setuid(getuid()) then the real & effective uids would both
become the login uid.

The only problem I can find with the original message is the subsequent call
to geteuid(), the problem is that, at the time of calling, geteuid() would
return the login uid & not the uid of the owner of the program. I believe
that the calling sequence should be

1. SavedUID=geteuid()
2. setuid(getuid())
3. system()
4. setuid(SavedUID)

Security wise, I don't think there are any major problems (and few minor ones)
but it really depends on what the program is attempting to do.
--
=============================================================================

Nigel Johnston, Datascheme Limited, Silsden, England.

 
 
 

1. Security holes in VGA setuid-root utils

My site was broken into a few months ago using one of the VGA utilities in
/usr/bin that was setuid-root.  It has a hole which allows any file
(/etc/passwd in my case) to be overwritten.  I have since then removed the
setuid bit from it and other programs.

I would recommend against having these VGA utilities setuid-root.  In fact,
I set mine to be runnable by no one EXCEPT root.  Someone could break in
from offsite and tweak your VGA settings, preventing you from seeing what's
being done!  Has anyone else had experience with this hole?

Josh

--
       ______   printf("\x1B[1;35m\x1F\x1B[0m");            "Look to the/\
JoSH Lehan  /                                                future!"--/{}\

         \/                                  ^^^ Try Linux instead.  /______\

2. diff

3. Security hole if man-2.0a2 installed setuid

4. info:

5. #! /bin/sh - setuid - Why is it a security hole?

6. locked page handling

7. AIX setuid/setgid security hole

8. Faster PCI Ethernet Adapter

9. SETUID STRIPTS ARE A SECURITY HOLE

10. Security holes in VGA setuid-root utils

11. Security Hole on webservers run on variuos OS, How to close UNIS hole

12. best-of-security mailing list (was: Solaris 2.5 Security Hole: local users can get root)

13. Really serious security hole in Microport Unix (Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386)