[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