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

[Kim Kimball]

This is a multi-part message in MIME format.
--------------030204070403000009030801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>
>
>   

--------------030204070403000009030801
Content-Type: text/x-vcard; charset=utf-8;
 name="dhk.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="dhk.vcf"

begin:vcard
fn:Dexter  'Kim' Kimball
n:Kimball;Dexter 
email;internet:dhk@ccre.com
tel;work:970-207-1474
tel;fax:866-514-9676
tel;home:970-215-6359
tel;cell:818-726-6392
x-mozilla-html:TRUE
version:2.1
end:vcard


--------------030204070403000009030801--