Bug 196326
| Summary: | IPv6: bad interaction between tcp_wrappers and DNS, vsftpd | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Steve Bonneville <sbonnevi> | ||||
| Component: | tcp_wrappers | Assignee: | Tomas Janousek <tjanouse> | ||||
| Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHBA-2007-0566 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-11-15 15:59:30 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 246216 | ||||||
| Attachments: |
|
||||||
|
Description
Steve Bonneville
2006-06-22 15:56:17 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 release. 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 "127.0.0.1 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.
I decided to modify it to treat localhost and localhost.localdomain as equivalent. Regarding comment #6, the line in /etc/hosts 127.0.0.1 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. 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) 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. 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. http://rhn.redhat.com/errata/RHBA-2007-0566.html |