On Wed, 2013-08-07 at 18:01 +0000, Adamson, Andy wrote:
>
> On Aug 7, 2013, at 12:54 PM, "Myklebust, Trond"
> <Trond.Myklebust@xxxxxxxxxx>
> wrote:
>
> > On Mon, 2013-07-22 at 12:42 -0400, andros@xxxxxxxxxx wrote:
> > > From: Andy Adamson <andros@xxxxxxxxxx>
> > >
> > > As per RFC 3530 and RFC 5661 Security Considerations.
> > >
> > > Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state
> > > whenever possible"
> > > uses the nfs_client cl_rpcclient for all clientid management
> > > operations.
> >
> > Why?
>
>
> To protect the integrity of the fs_locations server list.
>
> > From a security perspective, how is this any different from doing a
> > READLINK, for instance?
>
>
> fs_locations differs from READLINK in that compromising the
> fs_locations attribute server list can result in all of the client
> traffic under a junction redirected by an attacker.
I repeat: how is this in any way, shape or form different from READLINK?
>
> 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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
