A flaw was found in the tcp_wrappers related to the handling of hostnames specified in the host access rules in /etc/hosts.allow and /etc/hosts.deny. Problem affects applications that call hosts_ctl() tcp_wrappers interface function, such as net-snmp snmpd or OpenLDAP daemons. Client's IP address was not corrected looked up to a hostname by tcp_wrappers, hence any access rules containing hostnames were not matched. If the hostname was used in the allow rule, this could result in the access being incorrectly denied. Hostnames used in the deny rule may result in the access being incorrectly allowed, bypassing intended access restrictions. This issue was previously fixed as bug (access incorrectly denied) and patches are available in Red Hat Enterprise Linux 5 (RHBA-2007:0565) and current Fedora versions. Patch in Fedora package CVS: http://cvs.fedoraproject.org/viewvc/rpms/tcp_wrappers/devel/tcp_wrappers-7.6-220015.patch Similar problem was not confirmed for applications using tcp_wrappers' functions request_init / fromhost / hosts_access (such as ssh or vsftpd).
Using IP addresses instead of hostnames in "/etc/hosts.allow" and "/etc/hosts.deny" restricts access as expected, and can be used as a workaround until an update is installed.
Users of tcp_wrappers' hosts_ctl() function are affected by this bug. Most applications do not use this function, I am aware only of net-snmp.
(In reply to comment #9) > Users of tcp_wrappers' hosts_ctl() function are affected by this bug. Most > applications do not use this function, I am aware only of net-snmp. Doing a quick search, hosts_ctl() seem to be used by a bunch of other projects, including OpenLDAP, nfs-utils, portmap, exim, gdm, ... I've not reviewed all uses to see if there may be something else that may be preventing this problem for particular app, just a quick list of possible suspects.
Looking deeper into this, the problem only occurs when application calling hosts_ctl passes something else than hostname resolved from the IP address of the connecting client as the second argument of the call. That "something else" is usually STRING_UNKNOWN, as suggested in the hosts_access(3), however man page fails to detail consequences of using this as a replacement argument. However, some applications seem to use "" (empty string) instead. On the vanilla tcp_wrappers, there's no real difference, as STRING_UNKNOWN / "unknown" is set instead on the first eval_hostname call. However, that case is not handled correctly by this patch though: http://cvs.fedoraproject.org/viewvc/rpms/tcp_wrappers/devel/tcp_wrappers-7.6-220015.patch + /* If the address field is non-empty and non-unknown and if the hostname + * field is empty or unknown, use the address field to get the sockaddr + * and hostname. */ + if (strlen(request->client->addr) && + HOSTNAME_KNOWN(request->client->addr) && + (!strlen(request->client->addr) || + !HOSTNAME_KNOWN(request->client->name))) Comment mentions "hostname field is empty or unknown", but incorrectly checks address again. Therefore, hosts_ctl(service, "", ...) and hosts_ctl(service, STRING_UNKNOWN, ...) may yield different results. But that's rather an undocumented corner case. It's not too obvious from the hosts_access(3) man page that using STRING_UNKNOWN may render some rules unusable. So it may be argued whether this is tcp_wrapper or applications bug. The above change seems reasonable though, as it does not introduce the overhead of hostname lookup when no hosts access rule is specified for particular service. Changing tcp_wrappers can "fix" affected services to what most likely was authors intention.
(In reply to comment #20) > > + /* If the address field is non-empty and non-unknown and if the hostname > + * field is empty or unknown, use the address field to get the sockaddr > + * and hostname. */ > + if (strlen(request->client->addr) && > + HOSTNAME_KNOWN(request->client->addr) && > + (!strlen(request->client->addr) || > + !HOSTNAME_KNOWN(request->client->name))) Using this condition with request->client->name == "" renders rules with hostnames in hosts.allow/deny unusable, i.e. these rules are not taken into account when allowing/rejecting access to the service. Tested on RHEL4/tcp_wrappers-7.6-37.7.el4 and RHEL5/tcp_wrappers-7.6-40.6.el5
Will be fized in tcp_wrappers-7.6-55.fc11
Thank you! Updated patch: http://cvs.fedoraproject.org/viewvc/rpms/tcp_wrappers/devel/tcp_wrappers-7.6-220015.patch?view=markup
Discussion with the original upstream author: http://thread.gmane.org/gmane.comp.security.oss.general/1651 The original behavior is considered the expected and documented one, automated host name resolution in hosts_ctl is undesired in certain cases, such as in port mappers: http://article.gmane.org/gmane.comp.security.oss.general/1664
Wietse is right, we can get into problems with recursion on nis and maybe with speed or power penalty on others. I'm think that, the patch as is done is not so clever to resolve address on demand, but do it everytime before check, even if in hosts.{allow|deny} are ip addresses. Corect me if I'm wrong.
(In reply to comment #29) > Wietse is right, we can get into problems with recursion on nis This one should be rather specific to portmap, and mitigated by all local access being allowed without consulting tcp_wrappers. > and maybe with speed or power penalty on others. I'm think that, the patch as > is done is not so clever to resolve address on demand, but do it everytime > before check, even if in hosts.{allow|deny} are ip addresses. Corect me if > I'm wrong. The resolution is only done when needed, during the first call to eval_hostname, that only happens when hostname-based rule is found for the service. If you have no rule, or only IP based rules, there's no lookup penalty as far as I can see.
Proposed change was rejected upstream as causing undesired change of expected behavior (see comment #28), we're not going to introduce the change to products where it isn't already.
2009-05-21 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0786 ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This was originally intended for a report about TCP Wrappers and the hosts_ctl API function, but further investigation showed that this was documented behavior by that function. Notes: Future CVE identifiers might be assigned to applications that mis-use the API in a security-relevant fashion.