Re: Samba 3.x + kernel 2.6.x local root vulnerability
From: Urban Widmark (urban_at_teststation.com)
Date: 02/11/04
- Previous message: Mark Litchfield: "Update - CheckPoint Vulnerabilities"
- In reply to: Frank Louwers: "Re: Samba 3.x + kernel 2.6.x local root vulnerability"
- Next in thread: Darren Reed: "Re: Samba 3.x + kernel 2.6.x local root vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 11 Feb 2004 22:42:26 +0100 (CET) To: bugtraq@securityfocus.com
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;
- Previous message: Mark Litchfield: "Update - CheckPoint Vulnerabilities"
- In reply to: Frank Louwers: "Re: Samba 3.x + kernel 2.6.x local root vulnerability"
- Next in thread: Darren Reed: "Re: Samba 3.x + kernel 2.6.x local root vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
