Bug 196326 - IPv6: bad interaction between tcp_wrappers and DNS, vsftpd
Summary: IPv6: bad interaction between tcp_wrappers and DNS, vsftpd
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: tcp_wrappers
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Tomas Janousek
QA Contact: David Lawrence
Depends On:
Blocks: 246216
TreeView+ depends on / blocked
Reported: 2006-06-22 15:56 UTC by Steve Bonneville
Modified: 2007-11-30 22:07 UTC (History)
0 users

Clone Of:
Last Closed: 2007-11-15 15:59:30 UTC

Attachments (Terms of Use)
a little test (1.22 KB, text/x-csrc)
2007-06-27 11:15 UTC, Tomas Janousek
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0566 normal SHIPPED_LIVE tcp_wrappers bug fix update 2007-11-14 16:27:09 UTC

Description Steve Bonneville 2006-06-22 15:56:17 UTC
Description of problem:

TCP wrappers seems to have problems matching by hostname if a remote
host has both IPv6 and IPv4 addresses but connects using IPv4, even
if the local tcp-wrapped service is currently IPv4-only.
When using tcp_wrappers to control access to vsftpd, setting the rule
  ALL: localhost
in /etc/hosts.allow does not match connections from if DNS
contains the resource records
  localhost. IN A
  localhost. IN AAAA ::1

I tested this by additionally setting ALL:ALL in /etc/hosts.deny.

However, connections from ::1 work if listen_v6=YES has been set 
and listen=YES has been unset in /etc/vsftpd/vsftpd.conf.  The
connections from are still blocked.  It appears that 
when tcp_wrappers matches the hostname to an IP address, if it 
gets an IPv6 address, it only uses that, and doesn't match 
against the IPv4 address.  This can be tested by using the command
"telnet ::1 21" as a IPv6-aware FTP client.

When matching by hostname, tcp_wrappers should be matching connections
from *either* IPv4 or IPv6 adddresses belonging to the host.

Version-Release number of selected component (if applicable):

Comment 2 RHEL Product and Program Management 2007-05-09 10:09:16 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 6 Tomas Janousek 2007-06-27 11:15:45 UTC
Created attachment 157994 [details]
a little test

tcp_wrappers did not resolve the hostnames given in the hosts.{allow,deny}
files. It resolved the address of the connection to a hostname. As a solution
to another bug I modified it to resolve the hostnames but it seems I'll have to
remove that, so I came back to this one.

It might be caused by the contents of your /etc/hosts. If you have something
like " localhost.localdomain localhost", then the only address it sees
is localhost.localdomain. I'm attaching a little test program that shows
whether this is the case.

I may modify the code to treat localhost and localhost.localdomain as they're
the same, or we can agree that this is a misconfiguration on your side and
close it.

Comment 7 Tomas Janousek 2007-06-29 11:05:56 UTC
I decided to modify it to treat localhost and localhost.localdomain as equivalent.

Comment 9 Steve Bonneville 2007-06-29 16:59:09 UTC
Regarding comment #6, the line in /etc/hosts  localhost.localdomain localhost

shouldn't be considered a misconfiguration on my side, since that is what is set
by default by our installer.  

Also, all aliases on the line in /etc/hosts should resolve; that's the point of
having aliases on the line, after all.  If it doesn't, that should be a new bug.

Comment 11 Tomas Janousek 2007-07-09 14:28:28 UTC
By misconfiguration I meant the use of "localhost" instead of
"localhost.localdomain" in the hosts.allow file, not in the hosts file.

Basically, the problem is that the hostnames in hosts.allow/deny are not
resolved at all. The address of the client is resolved to the corresponding
hostname and that hostname is then used. And as far as I know, the glibc
functions to resolve an address to a hostname return only one hostname and I'm
not sure whether it is correct for an address to have more than one reverse
record at all.

Then the question is whether we should add the support for resolving the
hostnames in hosts.allow/deny files. It may open some possibilities for
DNS-based attacks.

(on the other hand, though, the issue with localhost vs. localhost.localdomain
is quite common and is therefore fine to work around)

Comment 12 Steve Bonneville 2007-07-09 15:13:32 UTC
Ah.  Interesting, that's not clearly documented, but that makes perfect sense.  

The RFCs are contradictory, but in practice the implementations I've seen allow
the address of the client to resolve to a single host name (each address in DNS
must have no more than one PTR record).  

The silly localhost.localdomain entry in /etc/hosts makes the name localhost in
hosts.allow not a FQDN, and we never check DNS since we have a match in
/etc/hosts.  Names that aren't FQDNs probably are not allowed to work in TCP
wrappers because to be "safe" we'd have to do something that would be the moral
equivalent of matching with PARANOID, which is more work.

For RHEL5, the localhost6 entry probably complicates things further, but I have
not tested that scenario, and this was on RHEL4.

Using hostnames for access control in TCP wrappers already opens some DNS-based
attacks, but this is one more nail in the coffin.  That argues that if this
security mechanism is used, you should really be filtering on IPs for better
control (even though that is subject to various attacks as well).

I'm going to bounce comment #11 off of the GLS instructional team for their
edification and further feedback.

Comment 13 errata-xmlrpc 2007-11-15 15:59:30 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.