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

[Jeffrey Hutzelman]

On Wednesday, March 28, 2007 04:16:38 PM -0500 "Christopher D. Clausen" 
<cclausen@acm.org> wrote:

> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>> On Friday, March 23, 2007 10:04:28 AM -0400 Jeffrey Altman
>> <jaltman@secure-endpoints.com> wrote:
>>> Kim Kimball wrote:
>>>> I'm still wondering if
>>>>
>>>> a.  Removing system:anyuser from ACLs will prevent this privilege
>>>> escalation
>>>> b.  Removing system:anyuser from ACLs except "system:anyuser l" will
>>>> prevent the privilege escalation (i.e. the only occurrence of
>>>> system:anyuser is with l permission)
>>>>
>>>> Any definitive conclusions?
>>>
>>> As has been discussed on this list over the last few days, modifying
>>> the contents of unprotected data retrieved via anonymous connections
>>> is just one form of attack that can be executed.
>>
>> What Jeff is trying to say is "no".
>> Changing ACL's will not prevent this attack.
>> Changing servers will not prevent this attack.
>> Period.
>>
>> The only way to prevent this attack is for clients not to honor suid
>> bits from sources not trusted _by the client_.  Since the current AFS
>> client has no way to obtain a secure connection to the fileserver
>> with which the user cannot tamper, all sources must be considered
>> untrusted.
>
> If there was a way to make the client only use encrypted connections
> (force fs setcrypt on and ignore unencrypted connections) would that be
> sufficient to prevent the privilege escalation?

No.  Even if you could do that, the connections are encrypted and 
authenticated using keys known to the user making the request.  So a user 
can spoof the response to his own (authenticated) request, indicating that 
a file is suid 0 when it really is not.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA