Re: [Tiger-user] Warning about an inetd entry

[Javier Fernández-Sanguino Peña]

On Tue, Nov 05, 2002 at 10:13:49AM -0800, Bob Hall wrote:
> Hi,
> 
> I wanted to ask a question concerning a particular warning
> issued by TIGER. This warning comes from the module that

        That's great (and I would like to see more questions like this)

> checks the inetd entries from /etc/inetd.conf. The warning
> is of the form:
> 
>  --WARN-- [inet008] inetd entry for XXXXX uses `YYYYY'
>  which contains `ZZZZZ' which is not owned by root (owned by WWW).
> 
> for the service name XXXXX, program YYYYY, directory ZZZZZ
> (owned by user WWW) and user WWW. (This is for a COTS product,
> installed per the vendor's instructions.)
> 
> Now the inetd.conf entry in question has a user ID of WWW.
> YYYYY is a root-owned symbolic link to a binary file that
> is setuid WWW. So could somebody explain to me why this is
> a potential security vulnerability? Isn't the service being
> run as real and effective UID WWW, so it has less privileges
> than if it was run by root?

        Ummm... why don't you check? I'm afraid it's possible to 
preserve the callers priviledges. The called binary has to explictly drop
root priviledges.

        Consider the following:
$ id
uid=1000(jfernandez) gid=1000(jfernandez) groups=1000(jfernandez)
$ cat trojan.c
#include <unistd.h>

int main (int ac, char **arg) {

        setuid(0);
        setgid(0);
        execv("/usr/bin/id",arg);
        exit(0);
}
$ gcc -o trojan trojan.c
$ chmod +s trojan
$ ls -la trojan
-rwsr-sr-x    1 jfernand jfernand     5119 Nov  6 20:27 trojan
$ sudo -s
# ./trojan
uid=0(root) gid=0(root) groups=0(root)
# su - nobody
$ ./trojan
$ ./trojan
uid=65534(nobody) gid=65534(nogroup) euid=1000(jfernandez) 
egid=1000(jfernandez) groups=65534(nogroup)

However, if I remove the setuid/setgid calls to the trojan:
# ./trojan
uid=0(root) gid=0(root) euid=1000(jfernandez) egid=1000(jfernandez)
groups=0(root)

¿See? Root can "escape" from the setuid restrictions, whileas other
users cannot.

        I have browsed briefly through Google and some references [1]
[2] [3] come up. If you take a look at [4], I quote:

- setuid, setgid - when set on an executable file, executing the file will
set the process' effective UID or effective GID to the value of the file's
owning UID or GID (respectively). All Unix-like systems support this. In
(...)

That is, the *effective* uid/gid is set, but the real uid/gid remains.
Unless the program drops priviledges (and depends on how it is done) then
it can still "recover" root. From the setuid(2) manpage:

       If the user is root or the program is setuid root, special
       care must be taken. The setuid function checks the  effec­
       tive  uid  of  the  caller and if it is the superuser, all
       process related user ID's are set to uid.  After this  has
       occurred,  it is impossible for the program to regain root
       privileges.

In any case. I'm no expert so I feedback from others is welcome.

        Regards

        Javi


[1]
http://security-archive.merton.ox.ac.uk/security-audit-200007/0069.html
[2] Apache issues with inetd (not dropping priviledges):
http://www.apacheweek.com/issues/96-06-07.html
[3] Linux capabilities and setuid in the filesystem
http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt
[4] Secure Programming HOWTO (for Linux)
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/files.html

pgpRk7QYNZIAc.pgp
Description: PGP signature