[OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2007-001: privilege escalation in Unix-based clients

[Dr A V Le Blanc]

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