On Thu, Jul 16, 2009 at 05:10:44PM -0400, Trond Myklebust wrote: > On Wed, 2009-07-15 at 17:42 -0400, Chuck Lever wrote: > > TI-RPC rpcbind operations provide not just a port number, but a full > > socket address the client should connect to. This allows rpcbind to > > redirect RPC traffic to specific network interfaces or servers. The > > Linux kernel rpcbind client implementation currently ignores the > > address. > > > > Expand the ->set_port transport method so an address is passed to > > transports during an RPC bind operation. Additional changes to > > individual client transports will be required to replace the peer > > address after an rpcbind operation. > > Now I'm worried. We've just spent a lot of time implementing RPCSEC_GSS > security, and yet we're going allow an AUTH_SYS-based RPC call to tell > us to change an IP address that the user supplied us with? It was bad > enough when we allowed it to set the port number... The authentication of the server will use whatever hostname was supplied on the commandline, so should still provide some protection. On the other hand: with krb5 (as opposed to krb5i or krb5p), a man-in-the-middle attack that keeps the rpc headers and replaces the body is always possible. But if you can redirect the client to a port/ip address under your control, that might simplify the attack significantly. Similarly, sniffing non-krb5p traffic might become simpler. It might also simplify denial of service attacks (possibly with the goal of making the user give up on gss and downgrade to auth_sys?). An attacker could do the same stuff with dns, I suppose. --b. -- 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
