Re-send due to my mailer adding html to the message, and thus being rejected by [email protected]
-->Andy
Begin forwarded message:
> From: "Adamson, Andy" <[email protected]>
> Subject: Re: [PATCH 2/4] NFSv4.1 Use clientid management rpc_clnt for fs_locations
> Date: August 7, 2013 2:24:31 PM EDT
> To: "Myklebust, Trond" <[email protected]>
> Cc: "Adamson, Andy" <[email protected]>, "[email protected]" <[email protected]>
>
>
> On Aug 7, 2013, at 2:19 PM, "Myklebust, Trond" <[email protected]>
> wrote:
>
>> On Wed, 2013-08-07 at 14:04 -0400, Trond Myklebust wrote:
>>> On Wed, 2013-08-07 at 18:01 +0000, Adamson, Andy wrote:
>>>>
>>>> Here is the attack as described in 3530bis Security Considerations
>>>> section:
>>>>
>>>>
>>>> The second operation that should definitely use integrity protection
>>>> is any GETATTR for the fs_locations attribute. The attack has two
>>>> steps. First the attacker modifies the unprotected results of some
>>>> operation to return NFS4ERR_MOVED. Second, when the client follows
>>>> up with a GETATTR for the fs_locations attribute, the attacker
>>>> modifies the results to cause the client migrate its traffic to a
>>>> server controlled by the attacker.
>>>
>>> You can the exact same thing by changing the READLINK results.
>>
>> The attack is: change the unprotected LOOKUP results to point to a
>> symlink, then feed '/net/<evil-ip-address>/my/evil/pathname' into
>> READLINK.
>>
>> My point is that if you're on a network where the above is a potential
>> threat, then you should be using krb5i or, better yet, krb5p for _all_
>> operations. It's not sufficient to single out fs_locations for special
>> treatment.
>
> In that case, why did you accept commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible" ?
>
> -->Andy
>
>>
>> --
>> Trond Myklebust
>> Linux NFS client maintainer
>>
>> NetApp
>> [email protected]
>> http://www.netapp.com
>