On Wed, 22 Jun 2011 13:32:38 -0400 Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 22 Jun 2011 10:50:11 -0600 > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > Thanks. > > > > This is a security problem, but I don't want to lose sight of the original cause of this bug, which was my lack of understanding of the function of the old code and the API contract (return only _one_ address). > > > > For extra credit, we might check if statd has a similar issue when it matches addresses. > > > > I don't think statd is vulnerable, as best I can tell. I don't see any > places where we do a getnameinfo on an address and then go and use that > to get a list of addresses with getaddrinfo. > > Please do double check me on this though. I go on vacation next week > and I think my brain might already have left. > Agggh... my eyes tend to glaze over whenever I try to think about statd :-( However: statd gets MON/UNMON requests from the kernel lockd, and NOTIFY requests from other hosts that have rebooted. The MON/UNMON requests can only contain a host name or IP that has been explicity requested locally so we have to basically trust though - though all we do with them it talk to the remote host a bit. The NOTIFY request contains a host name and if we are monitoring anything that which has that name, we assume that it has rebooted. The remote host that sends the NOTIFY could well be lying, but there is no a whole lot that we can do about that. This is a fundamental issue in the protocol rather than any mishandling of host name lookup. So I think statd looks as safe as it ever has been. NeilBrown -- 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
