[OpenAFS-announce] OpenAFS Security Advisory 2007-001: privilege escalation in Unix-based
Derrick J Brashear
Tue, 20 Mar 2007 15:13:26 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
OpenAFS Security Advisory 2007-001
Topic: setuid (privilege escalation) in OpenAFS Unix based clients
Last Update: 20-Mar-2007
Affected: OpenAFS 1.0 - 1.4.3, OpenAFS 1.5.0 - 1.5.16
A user with network access and knowledge of client cache contents can
promote a file to a setuid mode and any owner including root.
Because AFS cache managers do not use authenticated connections for
non-user-authenticated sessions, checks for cache coherency are done
over an unprotected connection if they are not being done for an
authenticated user. Because of this it is possible to spoof a false
status for files in the cache.
The AFS cache manager on platforms which offer privilege based on file modes
are vulnerable to such attacks.
There are no known publicly-available exploits for this vulnerability at
An attacker with knowledge of a file in the client can spoof a
FetchStatus reply with a setuid mode and root owner after flushing the
cache locally to invalidate the file status.
If the executable file is subsequently run and setuid status for the cell is
not disabled, privilege escalation will take place. Variants of this attack
may be possible without local client access if the attacker knows of specific
files being run from AFS on the client system.
All releases of OpenAFS 1.0.x, 1.1.x, 1.2.x, and 1.3.x.
All releases of OpenAFS 1.4.x, up to and including OpenAFS 1.4.3.
All releases of OpenAFS 1.5.x, up to and including OpenAFS 1.5.16.
The OpenAFS project recommends that users with systems which could be
compromised by privilege escalation upgrade to OpenAFS version
1.4.4 or newer. Only clients need to be upgraded. Note that this
vulnerability does not apply to Windows systems.
The latest stable OpenAFS release is
always available from http://www.openafs.org/release/latest.html.
For those who are unable to upgrade, setuid status can always be
disabled by running, as the super user on any client:
fs setcell -cell (local cell) -nosuid
This announcement and code patches related to it may be found on the
OpenAFS security advisory page at:
The main OpenAFS web page is at:
Thanks to Benjamin Bennett from the Pittsburgh Supercomputing Center for
reporting this issue.
Client systems are not required to have a Kerberos key cached, and
those which do would likely not have an AFS identity precreated for them.
Connections other than those on behalf of a user are thus not as
general practice authenticated, although it is theoretically possible to
Because the connection is not authenticated it is possible to spoof network
traffic from the server without it being detected. Trusting unauthentic server
answers to allow assignment of proper privilege level can allow privilege
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
-----END PGP SIGNATURE-----