home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.aix
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!cs.utexas.edu!hermes.chpc.utexas.edu!jones
- From: jones@chpc.utexas.edu (Willaim L. Jones)
- Subject: Re: AIX setuid/setgid security hole
- Message-ID: <1992Dec17.203701.22872@chpc.utexas.edu>
- Organization: The University of Texas System - CHPC
- References: <1992Dec17.192558.23830@mintaka.lcs.mit.edu>
- Date: Thu, 17 Dec 92 20:37:01 GMT
- Lines: 33
-
-
-
- >From: mcharity@lcs.mit.edu (Mitchell N Charity)
- >
- >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
-
-
-