Topics: AIX, Security, System Admin

SUID

Always watch out for files with the SUID bit set; especially if these are files that are not on the AIX system by default. Before any vendor or application team installs additional software on the AIX system, it may be worth file to run the following command, to discover any files with the SUID bit set:

# find / \( -perm -2000 -o -perm -4000 \) -type f -ls
Save the output of this command for later reference. Once the vendor or application team is done installing their application and/or database software, run the same command again, to discover if any newly created files exist, especially those that are owned by user root and have the SUID bit set. This allows other users to run the command as if they we're root.

The SUID bit can only be set on binary executables on AIX (starting with release 3.2.5 of AIX). Other UNIX operating systems, such as Fedora, may allow scripts to run with SUID bits set. On AIX it is allowed to set the SUID bit on a script, but AIX simply ignores it, and runs the script as the user who started the script, not using the account that owns the script, because this would be a huge security hole.

However, it is still very easy to write a C program that does the trick. The following example is a program called "sushi". The source code of the program, sushi.c, looks like this:
#include <stdio.h>
#include <time.h>

char *getlogin();

#define LOG_FILE "/tmp/sushilog"

main(argc, argv)
int argc;
char **argv;
{
  char buf[1024], *p=buf;
  int i, t;
  FILE *log;
  char msg[BUFSIZ], *ct, *name;

  *p='\0';
  for (i=1; i<argc; ++i)
  {
    strcpy(p, argv[i]);
    p += strlen(argv[i]);
    if (i < argc-1)
    {
      *p = ' ';
      ++p;
      *p = '\0';
    }
  }

  time(&t);
        ct = ctime(&t);
        name = getlogin();

  setuid(0);

  log = fopen(LOG_FILE, "a");
  if (!log)
    printf("Couldn't open log file!\n");
  else
    {
      sprintf(msg, "SUSHI: %s  %s  %s\n", name, buf, ct);
      fputs(msg, log);
      fclose(log);
      system(buf);
    }
}
The makefile looks like this (and makes sure the SUID bit is set when running "make"):
################################################
# Make rules                                   #
################################################

all:    sushi

sushi: sushi.o
        $(CC) -o $@ sushi.o

clean:
        rm -f *.o sushi

install:
        cp -p sushi /bin
        chown root  /bin/sushi
        chmod a+rx  /bin/sushi
        chmod u+s   /bin/sushi

################################################
# Source/object rules                          #
################################################

sushi.o: sushi.c
        gcc -c $*.c
Now, if this file is compiled as user root, a program called /bin/sushi will exists; it will be owned by user root, and the SUID will be set:
# ls -als /bin/sushi
8 -rwsr-xr-x  1 root root 6215 Sep  9 09:21 /bin/sushi
The sushi program basically takes everything entered as a parameter on the command line, and runs it. So if the file is owned by user root, it will run the parameter as user root. For example, if you would want to open a Korn shell as a regular user, and get root access:
$ /bin/sushi ksh
# whoami
root
This is something that you want to avoid. Even vendors are known to build backdoors like these into their software. The find command shown at the beginning of this article will help you discover commands as these. Note that the good thing of the sushi program shown above is, that it will write an entry into log file /tmp/sushilog each time someone uses the command.

To avoid users being able to run commands with the SUID set, you may want to add the "nosuid" option in /etc/filesystems for each file system:
/exports/install:
        dev             = "/exports/install"
        vfs             = nfs
        nodename        = fileserver.company.com
        mount           = true
        options         = ro,bg,hard,intr,nodev,nosuid,sec=sys
        account         = false
Especially for (permanently) NFS mounted file systems, it is a VERY good idea to have this nosuid option set, avoiding someone to create a sushi-like program on a NFS server, and being able to run the program as a regular user on the NFS client system, to gain root access on the NFS client; or if you want to mount a NFS share on a client temporarily, enable the nosuid by running:
# mount -o nosuid server:/filesystem /mountpoint
Check if it is set by running:
# mount | grep nfs
server   /filesystem   /mountpoint    nfs3   Sep 09 09:30 nosuid




If you found this useful, here's more on the same topic(s) in our blog:


UNIX Health Check delivers software to scan Linux and AIX systems for potential issues. Run our software on your system, and receive a report in just a few minutes. UNIX Health Check is an automated check list. It will report on perfomance, capacity, stability and security issues. It will alert on configurations that can be improved per best practices, or items that should be improved per audit guidelines. A report will be generated in the format you wish, and the report includes the issues discovered and information on how to solve the issues as well.

Interested in learning more?