Bugtraq mailing list archives
Re: tcpd -DPARANOID doesn't work, and never did
From: wietse () PORCUPINE ORG (Wietse Venema)
Date: Mon, 9 Nov 1998 16:56:23 -0500
The claim made in the SUBJECT line is incorrect. 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. Secondly, it depends on what native naming service the system uses. Naming services such as NIS have their own cacheing mechanisms, stopping the attack. You can immunize BIND against this and other short TTL attacks by patching the source or the executable file so that min_cache_ttl is, for example, 300 seconds. That is sufficient to stop the attack. The logdaemon rshd/rlogind aren't vulnerable to the attack, but that should not surprise anyone. Lastly, I'm responsible only for bugs in my own code. What happens in other rshd/rlogind implementations is beyond my control. Wietse According to "D. J. Bernstein" <djb () CR YP TO>:
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.
And, drop the connection if the hostname found with (1) does not match the hostname found with (2).
(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:
- Re: tcpd -DPARANOID doesn't work, and never did Wietse Venema (Nov 09)
- <Possible follow-ups>
- Re: tcpd -DPARANOID doesn't work, and never did Dave Barr (Nov 09)
- Re: tcpd -DPARANOID doesn't work, and never did D. J. Bernstein (Nov 09)
- Re: Several new CGI vulnerabilities Randal Schwartz (Nov 09)
- Re: tcpd -DPARANOID doesn't work, and never did Wietse Venema (Nov 09)
- Re: tcpd -DPARANOID doesn't work, and never did Darren Reed (Nov 10)
- Re: tcpd -DPARANOID doesn't work, and never did Greg A. Woods (Nov 10)
- Re: tcpd -DPARANOID doesn't work, and never did Jim Dennis (Nov 09)
- Re: tcpd -DPARANOID doesn't work, and never did D. J. Bernstein (Nov 10)
- Re: tcpd -DPARANOID doesn't work, and never did Wietse Venema (Nov 11)