[OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory
2007-001: privilege escalation in Unix-based clients
Derrick J Brashear
Wed, 21 Mar 2007 12:27:00 -0400 (EDT)
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!
> 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
>>>> 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
>> There simply is no other method available at the
>> moment within AFS.
>> Jeffrey Altman
>> Secure Endpoints Inc.