On Wed, 2013-04-03 at 10:40 -0400, Jim Rees wrote: > J. Bruce Fields wrote: > > Like Jim I don't understand how that fits the definition of a "man in > the middle" attack. > > If Bruce is having trouble too, I think the explanation needs to be > improved. But I think the latest patch set drops the talk about a > vulnerability, and I'm fine with that. Yeah I figured that just concentrating on the functional aspect of being able to work on networks with missing PTR records is sufficient to explain why this patchset is good :-) However let me give a try at explaining in a different way using the same example I gave before but from a different angle. - Assume user Alice has very important documents that are backed up daily to a server named secure.server.name where Alice can write to and nobody can read from. - Assume an attacker Eve, that is in the condition of intercepting and modifying all network traffic from Alice. - Assume there exist another server called public.server.name where Alice can write to and Eve can read from. Eve wants to fool Alice in mounting /export from public.server.name instead or secure.server.name so she can copy Alice's documents away. So Eve, manipulates traffic and when Alice's machine tries to talk to secure.server.name, Eve redirects all the traffic to public.server.name instead. (Can be done by a simple DNS poisoning attack that gives back to Alice computer the public.server.name IP address, or by actual DNAT on Alice's computer packets). Now, normally, if Krb5 authentication is used the mount would fail, because Alice would try to authenticate to public.server.com using a ticket she obtained to talk to secure.server.com (remember that Alice thinks she is mounting the secure.server.name share). Here the reverse DNS resolution performed by Alice's computer's rpc.gssd daemon is what allows Eve to successfully redirect Alice's mount instead. Because at the time Alice's computer needs to grab a ticket for the 'target' server, Eve fakes the DNS replies and tells Alice's computer that the destination name for the secure.server.name's IP address is 'public.server.name'. So with current behavior Alice's computer asks the KDC for a ticket for 'public.server.name' instead of 'secure.server.name'. Now Krb5 authentication does not fail anymore because Alice does have the 'right' ticket for the server it is connecting to. Alice authentication against the 'substituted' (by Eve, through packet redirection) server therefore succeeds, and her computer is fooled to think it really mounted secure.server.name when it really has mounted public.server.name, the cron job for the backup starts and copies all files to public.server.name, where Eve can find and access them. Call it MITM, call it something else, it's an attack, and we can prevent it. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
