Date: Tue, 10 Nov 1998 11:43:57 -0500
From: "Greg A. Woods" <woods@MOST.WEIRD.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: tcpd -DPARANOID doesn't work, and never did
[ On Tue, November 10, 1998 at 01:07:14 (-0000), D. J. Bernstein wrote: ]
> Subject: Re: tcpd -DPARANOID doesn't work, and never did
>
> The subject line is correct exactly as stated. -DPARANOID does not
> improve your computer's security. It has never improved anybody's
> computer security.
>
>[[....]]
I don't know if I've got the times exactly as necessary, but I think the
following is a slightly better detail of Dan's proposed attack:
0:00 Attacker connects to tcpd/busted.
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 for untrusted.badguy.com.
0:10 Attacker pours a cup of coffee, laughs at the tcpd code.
4:53 Attacker connects to tcpd/busted again.
4:54 tcpd asks for PTR result.
4:55 local DNS server hands back cached untrusted.badguy.com.
4:56 Local DNS server asks for A records untrusted.badguy.com.
5:04 Attacker sends back his IP address.
5:05 paranoid tcpd is happy and forks stupid "busted" program.
5:06 Local DNS server asks for PTR result (original sent at 0:02 has expired).
5:07 Attacker sends back trusted.toast.edu.
5:08 "busted" authorizes connection.
So far as I can tell this attack will not succeed for any modern rshd
with, or without, tcpd since the full forward and reverse check must be
done again by the forked service before comparing the determined
hostname against the list of trusted hosts.
> System administrators who thought that they were protecting themselves
> with -DPARANOID were actually deceiving themselves. As I said before,
> all of those systems were vulnerable until the vendors fixed the
> hostname lookups in rshd and rlogind.
I think most of us who've ever relied on DNS for any degree of
connection authentication and authorization have known that we need to
make our local nameservers authoritative for *all* the zones containing
data for any trust relationship determination.
There are sufficient disclaimers and warnings in the TCP Wrappers
package to any intelligent person aware of its limitations.
I think most of us also know that tcpd can't protect services that have
broken hostname authentication algorithms. I'm not sure where or how I
learned this (I can't find documentation in the TCP Wrappers package
that says this, particularly not in any prominent file), but I've always
had the impression that it's a widely known fact.
I do agree with Dan to the extent that any administrator relying solely
on TCP Wrappers to protect a broken rshd or rlogind service is not
getting the level of protection they think they are.
> You've done enough damage. Admit your mistake and turn off -DPARANOID.
Dan, in his usual way, has clouded an issue with a whole lot of
unnecessary and obfuscating "attitude".
Turning off -DPARANOID has *nothing* to do with whether or not TCP
Wrappers will do what it's designed to do. If it's turned off when
compiling tcpd it can be easily implemented on a per service basis by
including the name "paranoid" in the list of denied hosts. If it's
turned on then no service wrapped by tcpd will be able to accept a
connection from any host with incorrectly configured DNS regardless of
whether or not that service uses hostname based authentication.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
