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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ