In some mail from D. J. Bernstein, sie said: [...] > System administrators who thought that they were protecting themselves > with -DPARANOID were actually deceiving themselves. Any system administrator who relies on domain names for access control is deceiving themselves unless they control all of the name servers from which they could conceivably get a response from (and even then you'd need to be using BIND 8). But I'm sure you're aware of the follies there. > As I said before, > all of those systems were vulnerable until the vendors fixed the > hostname lookups in rshd and rlogind. > Wietse Venema writes: > > First of all, whether or not the attack fails depends on the BIND > > version being used; for example, the once widely-used BIND 4.8 > > forces the TTL to be at least five minutes, stopping the attack. > > No, it does not stop the attack. Let's go back to the videotape: > > 0:00 Attacker connects to tcpd/rshd. ``Heh, heh, heh.'' > 0:01 Local DNS server asks for PTR result. > 0:02 Attacker sends back untrusted.badguy.com, 5-minute TTL. > 0:03 Local DNS server asks for A records. > 0:10 Attacker pours a cup of coffee, laughs at the tcpd code. > 4:55 Attacker connects to tcpd/rshd again. > 4:56 Local DNS server asks for A records. > 5:04 Attacker sends back his IP address. ``That's me!'' > 5:05 Local DNS server asks for PTR result. ``I love caches.'' > 5:06 Attacker sends back trusted.toast.edu. > 5:07 rshd accepts connection. ``Elementary, my dear Wietse.'' You might find that BIND 8 (named) changes how the last few seconds of that happen. > Exercise for the reader: Find two faster solutions. > > > Secondly, it depends on what native naming service the system uses. > > Naming services such as NIS have their own cacheing mechanisms, > > stopping the attack. > > No, they do not stop the attack. You're making a fool of yourself. Unless NIS has been changed to use DNS, there is no DNS request for NIS to expire, nor NIS+. They're separate mechanisms for name resolution. But Wietse is correct (sort of). If you are using an intermediatry such as nscd which performs another level of caching, in front of named, then your results may be different, depending on how it combines the two differing gethostby* results. Remember, anything using gethostby* to retrieve hostname<>IP# does not get the TTL value and hence must make its own assumptions. [...] > instead of pestering their vendors for a > real fix? I assume you mean replace rsh/rlogin with ssh, correct ? Whilst I'm sure that would be "nice", it would probably only happen if it was shipped next to rsh/rlogin or in a manner that was truely backward compatible so that customers could continue to have things work (however insecure they may be). That's assuming vendors can implement it securely and/or make the right arrangements with SSH. But that's beside the real point of the "problem", and that "problem" is access control based upon domain names and domain names only. Log information should always list coupled IP# of the connection with hostname it purports to resolve back to.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:22:37 PDT