bugtraq - Re: Samba 3.x + kernel 2.6.x local root vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 11 Feb 2004 22:42:26 +0100 (CET)
From: Urban Widmark <urban@...tstation.com>
To: bugtraq@...urityfocus.com
Cc: Frank Louwers <frank@...nminds.be>
Subject: Re: Samba 3.x + kernel 2.6.x local root vulnerability


On Tue, 10 Feb 2004, Frank Louwers wrote:

> I think his point is this:
> 
> Image you have a user account luser on box foo. You do not have root on
> foo. However, you do have root on box bar. If you are allowed to
> smbmount stuff on foo as user luser, (which is a BadThing(tm), but
> default behaviour on some systems as it seems), and you smbmount a share
> on bar, and use that suid shell, you actually have root control on foo!

Some posts in this thread have made comparisons with how things work with
nfs. Unfortunately they are not valid, or this would indeed be just a
usage error. Here is my attempt at clarifying what the problem is.

The following combinations are needed to be vulnerable:

Client: Linux smbfs in 2.6.x or
                       2.4.25-pre8 with unix extensions in .config or
                       2.4.x + cifs-UE patches
Server: samba 3.x with unix extensions enabled (default?), or any other
        server that implements these extensions and supports suid flag or
        device nodes (I think samba3 is the only one).

- It is not a requirement that you mount the fs as a luser. Even if root
  does it there is still a vulnerability if the user can make a suid root
  binary on the server.

- Without UE, smbfs fakes the uid/gid as given to it by smbmnt 
  and a non-root user can't change it from his own. This is why you can't 
  set uid/gid with 2.4.
  With UE, smbfs ignores the uid/gid and instead accepts the server values 
  the same way nfs or any network fs with unix like id:s would.
  Same goes for file modes.

- root can set nosuid,nodev in the mount command as he would with nfs, but
  it does not affect the mount syscall because of what smbmnt doesn't do.

- The problem is really that smbfs, unlike nfs, isn't mounted using mount
  and thus has its own rules (mostly for nothing better than historical
  reasons). "mount -t smbfs ..." calls /sbin/mount.smbfs if found, which
  in turn calls smbmnt that executes the mount syscall.

I understand my patch to disable the suid+device code in smbfs was posted
earlier in this thread. Linus hated it because the problem isn't really in
the kernel. The following patch will be in future samba releases, possibly
modified so that root can enable suid for mounts as he specifies.


/Urban - Linux smbfs maintainer


diff -urN -X exclude samba-3.0.2-orig/source/client/smbmnt.c samba-3.0.2/source/client/smbmnt.c
--- samba-3.0.2-orig/source/client/smbmnt.c	Thu Aug 28 23:42:42 2003
+++ samba-3.0.2/source/client/smbmnt.c	Tue Feb 10 22:56:58 2004
@@ -240,7 +240,7 @@
                         data.dir_mode |= S_IXOTH;
         }
 
-	flags = MS_MGC_VAL;
+	flags = MS_MGC_VAL | MS_NOSUID | MS_NODEV;
 
 	if (mount_ro) flags |= MS_RDONLY;