AIX setuid/setgid security hole

AIX setuid/setgid security hole

Post by Mitchell N Chari » Sat, 19 Dec 1992 04:25:58



Bug:  setuid/setgid do not properly limit authority.
Example:
   A program running as root,
   after successfully calling setgid(100) and setuid(100),
   thus allegedly adopting guest/usr authority,
   can still delete files from root/security owned directories.
Security impact:
   User written programs which begin running as root,
   (in my case, a /bin/login replacement),
   and appear to safeguard the filesystem by becoming a unprivileged user,
   may in fact still have the authority to do significant damage.
Bug status:
  - I have begun the tortuous IBM support process.  No feedback yet.
  - I have heard that a related bug, and an associated workaround,
   were posted to this list.  Also that they were reported to IBM and CERT,
   and ignored by both.  ?

Demo:

Under AIX 3.2.1:
% more program.c
#include <unistd.h>
#include <stdio.h>
main (int argc,char**argv) {
  if( setgid( 100 ) <0) { perror("setgid failed"); exit(1); }
  if( setuid( 100 ) <0) { perror("setuid failed"); exit(1); }
  execv(argv[1],&(argv[1]));
  perror("execv failed");
  exit(1);

Quote:}

% cc -o program program.c
% su
# mkdir          foodir
# chown root     foodir
# chgrp security foodir
# chmod 775      foodir
# touch          foodir/foofile
# chown root     foodir/foofile
# chgrp security foodir/foofile
# chmod 775      foodir/foofile
# /bin/ls -dl foodir
drwxrwxr-x   2 root     security     512 Dec 17 13:14 foodir
# /bin/ls -l  foodir/foofile
-rwxrwxr-x   1 root     security       0 Dec 17 13:14 foodir/foofile
# ./program /bin/rm -f foodir/foofile
# /bin/ls -l  foodir/foofile
foodir/foofile not found

Note:
 If chmod 755 foodir, rather than 775, then permission is correctly denied.

 
 
 

AIX setuid/setgid security hole

Post by Willaim L. Jon » Sat, 19 Dec 1992 05:37:01



>Bug:  setuid/setgid do not properly limit authority.
>Example:
>   A program running as root,
>   after successfully calling setgid(100) and setuid(100),
>   thus allegedly adopting guest/usr authority,
>   can still delete files from root/security owned directories.
>Security impact:
>   User written programs which begin running as root,
>   (in my case, a /bin/login replacement),
>   and appear to safeguard the filesystem by becoming a unprivileged user,
>   may in fact still have the authority to do significant damage.
>Bug status:
>  - I have begun the tortuous IBM support process.  No feedback yet.
>  - I have heard that a related bug, and an associated workaround,
>   were posted to this list.  Also that they were reported to IBM and CERT,
>   and ignored by both.  ?

You forgot about group membership.  You need to do the following sequence:

    setgid(basegid);
    initgroups(user, basegid);
    setuid(user);

If you don't do this the user inherits the root groups which
includes security.  This should fix you problem.

Bill Jones

 
 
 

1. SETUID/SETGID security

Hi folks,

This may be a FAQ, but I don't seem to have been able to find
a definitive answer :

1.

What are the security problems involved in implementing

a) a setuid/setgid c program
b) a setuid/setgid shell script

2.

How do you overcome these problems ?
--


Unix System Administrator   Phone:    +61-7-834-2895
Department Of Transport     Fax:      +61-7-834-2911

2. file locks from multiple threads

3. Security holes in VGA setuid-root utils

4. NFS mount (non-root)

5. Security hole if man-2.0a2 installed setuid

6. Dump/restore on ext2fs

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

8. Interfacing a c prog with a shell prog

9. Security holes, and setuids

10. SETUID STRIPTS ARE A SECURITY HOLE

11. Security holes in VGA setuid-root utils

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

13. security hole in AIX 4.3.3