Bug#384922: NFS insecure without support for squashing multiple groups
retitle 384922 NFS root_squash broken without support for squashing multiple groups
severity 384922 critical
thanks
Dear Steve,
> [root_squash is] often circumventable ...
References (CERT kb, securityfocus BID, secunia advisory)? I do not know of
any (other than this bug) instances of defeating root_squash.
>> Is it documented that NFS must ...
> How is it the responsibility of the kernel ...
This bug was originally filed against NFS. I assert that it is not
documented, because there is no such "must".
> ... policy requirements ... that each package must satisfy ...
NFS (or kernel) must be secure while complying with policy requirements.
> ... consequence of *installing or using the software* ...
Using it in some common, reasonable way; following common UNIX knowledge,
and Debian-specific documentation; using root_squash as was intended.
> No, there are three vectors by which an attacker on the client can exploit
> this problem to get root on the NFS server:
>
> - the server's /usr/local is itself NFS-shared from server to client, and
> in the absence of squash_gids the attacker is able to directly trojan
> root's path
> - a filesystem is shared that allows the attacker to write an suid binary
> to the server, and the attacker is able to start arbitrary processes on
> the server using credentials of a compromised user account and thereby
> trojan root's path, *or* attack through another privileged group
> - a filesystem is shared that allows the attacker to write a file to the
> server that triggers some other user who is a member of a privileged group
> to execute an attack using their privileged group membership; most likely
> this would be done via shared home directories and shell startup
> configuration.
The attack I described does not fit well with either of your vectors.
The first vector surely does not apply. I think you meant "suid root" in the
second vector: then it does not apply, correctly prevented by root_squash;
there are no compromised accounts on the server. The third vector does not
apply, as there are no users in any privileged group on the server.
The issue in this bug is the mere existence of the staff group: the fact
that it is a root-equivalent, though without any member users, is sufficient
for the attack to succeed. The attack could be prevented by squash gid
trickery, or more simply by ensuring root has a sane PATH and/or by sane
ownerships on /usr/local. (I note that Debian policy is insane, but that is
not this bug.) Other UNIX distributions do not have root-equivalent users or
groups, thus their NFS services and root_squash options perform correctly.
> ... unwilling to yourself block these users' access to /usr/local.
None of my users have any (other than read) access.
> You're damn well free to ignore the policy when configuring your system. I
> have no idea where you got the idea that policy was binding on users.
Thanks. Could you please state that in #299007 also?
Still, Debian must be secure by default, out-of-the-box. I guess this bug
could be "solved" by asking NFS to document it needs non-default,
non-policy-compliant settings for it to function securely. But then those
settings would need to go into its setup scripts, and it would be in breach
of policy, triggering a "serious" bug and its removal from Debian.
Cheers,
Paul Szabo psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
Reply to: