Dr A V Le Blanc wrote:
On Tue, Mar 20, 2007 at 03:13:26PM -0400, Derrick J Brashear wrote:
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
this time.
IMPACT
======
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.
Hm, I have a difficulty about this one. We have a large number of systems
to which some thousands of users have access, virtually none of which
are authenticated in AFS. These systems have almost their entire
/lib, /bin, and all of /usr in AFS. A substantial part of them
would stop working if we had all suid/sgid programs disabled by
default. Short of copying every single binary of this kind to the
local disk and chmoding it, I can't think how we can cope with
setting suid off. Are we to have a permanent security hole? Or is
there another way of dealing with this?
-- Owen
If these are Linux systems, then you could try doing a loopback mount
out of AFS. It's not as flexible, but would still work and would allow
suid even when AFS disallows it.
The basics are make a big file and format it as ext2/ext3/squashfs, put
all of your binaries in it. Copy that file out to AFS and have clients
mount that file as /usr, /lib, /bin.
The other option is to use something like rsync to sync the file with
the local disk every hour or so. That would be a three line shell
script. Besides, having local copies of /bin, /lib, and /usr is handy in
the case of outages. rsync would copy the setuid/gid bits out of AFS, so
the setuid bit would work when copied local, but would be inept when run
directly from AFS.
Sincerely,
Jason
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
