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

[jimd () STARSHINE ORG (Jim Dennis)]

> 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" <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.

        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              consulting () starshine org
Proprietor, Starshine Technical Services:  http://www.starshine.org