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

[Derrick J Brashear]

you'd have to hijack the rx connection entirely or spoof all the relevan 
fetchdata replies, but it coyuld be done

On Wed, 21 Mar 2007, Kim Kimball wrote:

> DETAIL under ACKNOWLEDGMENTS, referring to 
> Benjamin Bennet from PSC seem less specific than 
> spoofing a FetchStatus reply.
>
> "Connections other than those on behalf of a user 
> are thus not as
> general practice authenticated, although it is 
> theoretically possible to do so.
> Because the connection is not authenticated it is 
> possible to spoof network
> traffic from the server without it being detected. 
> Trusting unauthentic server
> answers to allow assignment of proper privilege 
> level can allow privilege escalation. "
>
> My reading of this says that network traffic from 
> a server can be spoofed, in general, since an 
> anonymous user will operate over an 
> unauthenticated connection.  If so it seems it 
> would be possible to place a file in the cache as 
> well as spoof status.
>
> Those more knowledgeable please debunk!
>
> Thanks.
>
> Kim
>
>
> Jeffrey Altman wrote:
>> Jason Edgecombe wrote:
>> 
>>> Dr A V Le Blanc wrote:
>>> 
>>>> 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 issue is that copying files out of /afs that 
>> have the suid bit set
>> is not safe as long as the cache contents were 
>> populated using an
>> unauthenticated connection to the file servers. 
>> This is because when
>> unauthenticated connections are used there is no 
>> keying material
>> available to prevent modifications to either the 
>> status data that
>> indicates that a file should or should not be 
>> executed suid or the
>> contents of the file itself.
>> 
>> It is for this reason that suid is being 
>> disabled by default.  Of
>> course, if you want to execute processes out of 
>> /afs suid you can
>> do so simply by "fs setcell -cell <cellname> 
>> -suid".   You do not
>> need to use a loopback mount to work around the 
>> default settings of
>> the cache manager.
>> 
>> That being said, the only real workaround is to 
>> locally copy the
>> files using authenticated connections
>> 
>>   <obtain tokens>
>>   fs flush <dir>
>>   fs flush <file>
>>   cp -p <file> /local/path
>>   chmod xxx /local/path
>> 
>> and then execute the suid files from the local 
>> disk.
>> 
>> There simply is no other method available at the 
>> moment within AFS.
>> 
>> Jeffrey Altman
>> Secure Endpoints Inc.
>> 
>> 
>>