This note was sent to the Samba mailing list be my in July 1994. I
include it in the current version for your information.

Andrew Tridgell


=====

I have been investigating a potential security hole in Samba on some
operating systems.

The hole occurs because Samba becomes the connected user for brief
periods while processing requests. During this time it would (in
theory) be possible for a user to connect to the smbd process with a
debugger and change important internal structures. In theory they
could gain root access in this way.

Note that if the hole exists then it would not allow someone from
another machine to gain access. Only those with accounts on the system
can potentially take advantage of this.

I have written a short program to test a system to see whether it is
vulnerable to this kind of attack. Using this I have confirmed that
SunOS and Solaris are NOT vulnerable, but Linux is vulnerable. I have
not been able to test any other operating systems.

In particular I tested SunOS 4.1.3, Solaris 2.3 and Linux 1.1.32.

The difference is that SunOS and Solaris appear to reject ptrace()
requests if the eid of the calling process does not match both the
real uid and effective uid of the smbd process. Linux only tests the
effective uid of the called process, not the real uid. 

Interestingly the SunOS and Solaris manual pages imply that they are
not vulnerable to this attack, but for the wrong reason. They say you
cannot ptrace() a process if you can't send it a signal, or the
effective uids don't match. I found that I couldn't ptrace() but I
could send signals! So under SunOS and Solaris the hole does not
exist but there is a bug in the manual pages.

Any system which has NO_EID defined in the includes.h file will not be
vulnerable. Currently this is only CLIX. 

You are also not vulnerable if your log files report a "trapdoor uid
system".

Under Linux (and probably any other vulnerable OS) you can easily plug
the hole. You just need to make the smbd binary setgid to an empty
group. To do this do the following:

1) create a group with noone in it. do this by adding a line to
/etc/group like this:

samba::555:

note the 555 is not a magic number. Any unused number will do. Also
the name "samba" isn't special. It can be any name. Maybe "nobody" is
a better choice.

2) change the owner of the smbd file to group "samba" (or the group
name you chose above). eg:

chown .samba /usr/local/samba/smbd

3) make smbd setgid. eg:

chmod g+s /usr/local/samba/smbd

4) kill any existing smbd processes.

The reason this works is that Linux rejects ptrace() requests on sgid
or suid binaries.

I will soon submit a bug report to the Linux kernel channel so
hopefully this hole will be fixed properly in future kernel releases.

I now include below the program you can use to test whether your OS is
insecure. If you run Samba on a system other than SunOS, Solaris or
Linux then could you PLEASE run this to test whether you are
vulnerable. If you are vulnerable then try again after the setgid
fix. Please let me know the results. I would like to know as soon as
possible the status of the approx 20 different unixes supported by
Samba. 

I would also like to point out that exploiting this hole would be
extremely difficult. This test program merely tests whether it might
be possible, it does not actually do any damage. Changing it to do
damage would require someone with a detailed knowledge of Unix
internals. 

To use this program do the following steps:

1) put the code in a file called tstattach.c in the Samba source directory.
(it needs to find the includes.h file from the Samba source directory)

2) compile it with something like:

gcc -DSUN tstattach.c -o tstattach

where you replace SUN by your operating system (the same define as used in
the Samba Makefile)

3) become an ordinary user, not root. You can use "su - username" or
telnet or rlogin to do this.

4) connect to a home directory on your unix system using smbclient

5) use "ps auxw | grep smbd" to find the smbd process number. It must
be the one you just connected to with smbclient (look at the start
time)

5) run "tstattach PID" where PID is the process id of the smbd process you
found above. Note that you should not run this program as root.

6) do a few operations like "dir" with the smbclient you started above.

If the tstattach program reports "attached successfully - process is
insecure" then your system is vulnerable. If it just sits there and
doesn't say anything then you are not vulnerable. You can then use
control-c to kill it.

Note that if tstattach reports that you are vulnerable while you
weren't doing any smbclient commands then you probably have a trapdoor
uid system and you are not vulnerable. You can confirm this using the
log.debug file and looking for the word "trapdoor".

If you try tstattach then please let me know the results!

here is the tstattach.c file:

#include "includes.h"
#include <sys/ptrace.h>

main(int argc,char *argv[])
{
  int pid;
  
  if (argc < 2)
    {
      printf("Usage: tstattach PID\n");
      exit(0);
    }

  pid = atoi(argv[1]);
  while (1)
    if (ptrace(PTRACE_ATTACH,pid,0,0) == 0) break;

  printf("Attached successfully - process is insecure\n");
  kill(pid,SIGCONT);
}

