[8480] in bugtraq
Re: tcpd -DPARANOID doesn't work, and never did
daemon@ATHENA.MIT.EDU (Darren Reed)
Tue Nov 10 14:47:49 1998
Date: Tue, 10 Nov 1998 20:56:16 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To: djb@CR.YP.TO
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19981110010714.8866.qmail@cr.yp.to> from "D. J. Bernstein" at
Nov 10, 98 01:07:14 am
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.
