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