Hi David, On Wed, Feb 11, 2015 at 5:56 PM, David Ramos <daramos@xxxxxxxxxxxx> wrote: > Hi Trond, > > Thanks for the quick response. Your patch looks good to me. > > On Feb 11, 2015, at 2:42 PM, Trond Myklebust > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > > I can't see this issue as being exploitable without a fair amount of > > trouble because the above RPC request would be incoming on a TCP > connection that was initiated by the NFSv4.1 client. If someone can do > that level of spoofing, then they can cause all sorts of mischief for > the client. > > > That’s a fair point as far as spoofing. The attack vector I had in mind was > one in which a client is induced to mount an NFS volume on a malicious > server (either directly, through some DNS trickery, or via automount). Even > if the client shouldn’t trust the “mischievous" files being from the server, > we shouldn’t let the server crash the client machine. This is clearly not as > compelling as a client attacking a server, but I think it’s worth > considering. If you are operating in that kind of hostile environment, then you really should be using RPCSEC_GSS with krb5i or krb5p to protect your payloads. I'll admit that we don't yet have proper support for RPCSEC_GSS protection on the NFSv4.1 backchannel RPC requests, so the particular spoofing scenario described above is still possible, however the server and client will mutually identify each other via RPCSEC_GSS when the TCP connection is being set up. Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
