Bug 196326 - IPv6: bad interaction between tcp_wrappers and DNS, vsftpd
IPv6: bad interaction between tcp_wrappers and DNS, vsftpd
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: tcp_wrappers (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Janousek
David Lawrence
Depends On:
Blocks: 246216
  Show dependency treegraph
Reported: 2006-06-22 11:56 EDT by Steve Bonneville
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2007-0566
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 10:59:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Steve Bonneville 2006-06-22 11:56:17 EDT
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 06:09:16 EDT
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 07:15:45 EDT
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 07:05:56 EDT
I decided to modify it to treat localhost and localhost.localdomain as equivalent.
Comment 9 Steve Bonneville 2007-06-29 12:59:09 EDT
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 10:28:28 EDT
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 11:13:32 EDT
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 10:59:30 EST
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.