On Wed, Apr 03, 2013 at 12:03:38PM -0400, Simo Sorce wrote: > 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 :-) Definitely, you're fine. I was just nitpicking language, the problem's clear enough: > 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. Argh, sorry Simo, I didn't mean to make you write all that out. > Call it MITM, call it something else, This was literally my only complaint. The above doesn't sound to me like what I'd normally call a "man in the middle" attack. --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
