Message ID | 1423694562.7169.12.camel@primarydata.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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@primarydata.com> 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. Best, -David -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi David, On Wed, Feb 11, 2015 at 5:56 PM, David Ramos <daramos@stanford.edu> 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@primarydata.com> 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
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c index f4ccfe6521ec..02f8d09e119f 100644 --- a/fs/nfs/callback_xdr.c +++ b/fs/nfs/callback_xdr.c @@ -464,8 +464,10 @@ static __be32 decode_cb_sequence_args(struct svc_rqst *rqstp, for (i = 0; i < args->csa_nrclists; i++) { status = decode_rc_list(xdr, &args->csa_rclists[i]); - if (status) + if (status) { + args->csa_nrclists = i; goto out_free; + } } } status = 0;