Bugtraq mailing list archives

Re: tcpd -DPARANOID doesn't work, and never did


From: wietse () PORCUPINE ORG (Wietse Venema)
Date: Mon, 9 Nov 1998 19:57:58 -0500


I received a lot of private email followups to my response, and
found that many people misread Bernstein's post.

Rather than responding to each individually I'll do it here.

The scenario consists of four steps:

(1) tcpd does address->name lookup, to find out the client
    hostname.

(2) tcpd does name->address lookup, to find out the client
    address list.

(3) if there is a discrepancy, tcpd drops the connection.

(4) some other application, not tcpd, does address->name lookup
    and uses the result for "authentication" purposes.

Many people missed that steps 1-3 are done by tcpd, step 4 by the
application run under control of tcpd. Since 1 and 4 are done at
different times by different programs, an attacker can try to play
games with very short TTLs in DNS responses.

As mentioned in my earlier response, whether or not a short TTL
attack fails or succeeds depends on many factors, such as what BIND
version one uses, whether or not a native name service such as NIS
is being used, and so on.

If you are concerned about this and other attacks involving short
TTL values, patch the min_cache_ttl variable in the BIND source or
in the executable file and set it to, for example, 300 seconds.

        Wietse

D. J. Bernstein:
Once upon a time, rshd/rlogind checked for trusted hosts as follows:

   Use DNS PTR records to find a name for the remote IP address, and
   check that the name is in a list of trusted host names.

Of course, this check is worthless, even if you have secure IP and
secure DNS. An attacker simply sets up a PTR record from his own IP
address to one of your trusted host names.

This attack became widely known in mid-1991. Wietse Venema promptly
released a new version of his log_tcp package, with a tcpd -DPARANOID
option providing ``protection against rlogin and rsh attacks.'' System
administrators installed tcpd and breathed a collective sigh of relief.

But -DPARANOID didn't stop the attacks!

Here's the combined procedure used by tcpd -DPARANOID and rshd/rlogind
to check for trusted hosts:

   (1) Use DNS PTR records to find a name for the remote IP address.

   (2) Use DNS A records to find the IP addresses for that name.

   (3) Drop the connection if the remote IP address is not one of the
       IP addresses for that name.

   (4) Use DNS PTR records to find a name for the remote IP address,
       and check that the name is in a list of trusted host names.

The A records for all trusted hosts can be controlled locally. With
secure IP and secure DNS, there's no way for a trusted host name in #1
to survive the check in #3 unless the remote IP address is listed as an
A record for that name.

But who says the attacker has to use a trusted host name in #1? He
doesn't need a trusted host name until #4! The attacker simply

   * responds to the PTR query in #1 with a low-TTL name that points to
     an A record under his control;

   * pauses so that the PTR result is no longer cached;

   * responds to the A query in #2 with his IP address; and then

   * responds to the new PTR query in #4 with a trusted host name.

Nobody knows how many tcpd-``protected'' hosts were compromised through
this attack before vendors fixed their rshd/rlogind programs.

tcpd -DPARANOID is still the default today. People who try to use tcpd
for public services end up losing connections from thousands of hosts.
New sysadmins often have trouble tracking down the problem, since tcpd
doesn't take responsibility for its own error messages. I'm eliminating
tcpd from the qmail FAQ; the advantages of relying on familiar software
are outweighed by the -DPARANOID support hassle.

Cynics will note that there are many other examples of security scares
being exploited to sell software that adds far more inconvenience for
normal users than for attackers. No wonder security has such a bad name!

---Dan
1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html






Current thread: