> 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. Are you talking about the resolver libraries, or are you assuming that the clients will be talking to some caching NS under our administrative control? > 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" <djbat_private>: >> 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. Right. All this check proves is that the attacker has control of someone's reverse DNS mappings. >> 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. Oddly enough I've never heard Wietse claim that PARANOID provides "protection against rlogins and rsh attacks." His man pages describe the behavior of -DPARANOID and of the PARANOID keyword in the options file with no promises express or implied. Also anyone who thinks that PARANOID would protect from rsh attacks is deluded. You *at least* need anti-address spoofing at your perimeter/border firewalls/packet filters to even *hope* to prevent those attacks over those lines. rsh requests with spoofed source addresses can do all of their exploit within a single packet (never receiving the results of that --- but potentially opening up an *overt* channel back to themselves). I seem to recall that Wietse said as much in the class that I took from him. >> 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). Right. We're checking to see if there if the forward and reverse lookups are consistent. This means that we are extending our zone of trust (and exposure) to the maintainer of the zones which we list in our /etc/hosts.allow. Any sysadmin worth his salt should realize that address spoofing and tcp hijacking are at least a couple of remaining vulnerabilties. >> (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. Oh! So anyone one in any of our hosts.allow might be able to impersonate any other hosts in our hosts.allow. While it's an interesting weakness (sounds like a DNS race condition) it should hardly be a surprise to any sysadmin. The obvious problem is that there are two reverse lookups (in this case). One by tcpd and another by rshd/rlogind. One obvious solution (to this particular exploit) is to use versions of rshd/rlogind that are compiled with libwrap -- and to use that directly. Then only one PTR lookup is performed. Another method would be for tcpd to pass the reverse name to the rshd via a command line option (already supported on the tcpd side). It's actually kind of silly to do *two* PTR lookups for the same request. >> Nobody knows how many tcpd-``protected'' hosts were compromised >> through this attack before vendors fixed their rshd/rlogind >> programs. Nobody knows how many people practice wishful thinking when they read through a program's features. Anyone who thought that tcpd (with or without PARANOID checks) was some sort of "magic bullet" was and his sadly mistaken. It provides one set of tests. >> 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. None of my systems have -DPARANOID (most are straight Red Hat --- not personally compiled by me, FOR SHAME!) --- though all have the "extended options" available, and I can use the PARANOID keyword in any event. An FAQ is intended to answer *frequent* questions. Removing information from one fails in this basic intent. Mentioning that connection timeouts are likely to be caused by inconsistencies between forward and reverse lookups (as performed by tcpd and libwrap linked programs), and referring the reader to the tcpd man pages or some TCP Wrappers FAQ (is there one?) takes about 30 words! This is likely to be a "frequent question" regardless of whether you address it in your FAQ or not. >> 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! There may be "many examples of security scares ...." and this may be such an example. The cynic in me suggests that you found an interesting potential vulnerability and have chosen a sensationalist tone in which to present it. The cynic in me wonders if you haven't stirred up enough controversy recently, are feeling neglected, and looking for your flamefix. But then the cynic in me also wonders if this is some obtuse way to attempt to undermine the credibility of someone who has been working on a competitor to one of your products. The cynic in me has also heard that you are qmail's worst eneny. I hear that VMAILER should be shipping anytime now. I can't see where Wietse has promulgated any such scare and he certainly hasn't "sold" his utilities. (Not that I'm implying that you have --- last I heard qmail is free. So you don't appear to be motivated by financial profits). As for the inconvenience --- if you don't like it; don't use it. If you really don't like it, suggest something better, or just suggest that people "not do that." People who have unreasonable expectactions, and people who assume that their superficial understanding of a mechanism warrants unquestioned reliance on that understanding, will fail in their security efforts. -- Jim Dennis (800) 938-4078 consultingat_private Proprietor, Starshine Technical Services: http://www.starshine.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:22:34 PDT