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

Jason Edgecombe jason@rampaginggeek.com
Wed, 21 Mar 2007 09:53:27 -0400


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