[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0402092306280.5492@varg.mcpoolen.se>
Date: Mon, 9 Feb 2004 23:24:35 +0100
From: Michael Kjorling <michael@...rling.com>
To: Michal Medvecky <M.Medvecky@...cvut.cz>
Cc: Bugtraq <bugtraq@...urityfocus.com>
Subject: Re: Samba 3.x + kernel 2.6.x local root vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 9 2004, M.Medvecky@...cvut.cz wrote:
> share:/data/share# ls -l a
> - -rwsr-sr-x 1 root root 11716 Feb 8 12:39 a
>
> misko@...vakia:~$ ls -l pokus/a
> - -rwsr-sr-x 1 root root 11716 2004-02-08 12:39 pokus/a
> misko@...vakia:~$ pokus/a
> root@...vakia:~# id
> uid=0(root) gid=0(root) skupiny=1000(misko),0(root),29(audio),100(users),1034(mtr),1035(333)
> root@...vakia:~#
>
> 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@...rling.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+HSb3praYRAs0XAJ4paRauhUv9ZxfBGvIzmTd58lehNACfcinr
Np/I7ZBWNsHzFOfa6CzilTk=
=MT0N
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists