[8479] in bugtraq
Re: tcpd -DPARANOID doesn't work, and never did
daemon@ATHENA.MIT.EDU (Jim Dennis)
Tue Nov 10 14:47:42 1998
Date: Mon, 9 Nov 1998 20:49:02 -0800
Reply-To: Jim Dennis <jimd@STARSHINE.ORG>
From: Jim Dennis <jimd@STARSHINE.ORG>
X-To: Wietse Venema <wietse@PORCUPINE.ORG>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19981109215623.B4B12458A1@spike.porcupine.org> Message
Apparently From Wietse Venema <wietse@PORCUPINE.ORG> Dated Mon,
09 Nov 1998 16:56:23 EST.
> 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
