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  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 <>
Cc: Frank Louwers <>
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;
 	if (mount_ro) flags |= MS_RDONLY;

Powered by blists - more mailing lists