Bug 491095 - (CVE-2009-0786) CVE-2009-0786 tcp_wrappers: hosts_ctl() does not handle hostnames specified in /etc/hosts.{allow,deny} correctly
CVE-2009-0786 tcp_wrappers: hosts_ctl() does not handle hostnames specified i...
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
reported=20090311,source=redhat,publi...
: Reopened, Security
Depends On: 489703 489705 491106 491107
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 09:27 EDT by Jan Lieskovsky
Modified: 2009-08-19 06:57 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-22 09:44:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2009-03-19 09:27:48 EDT
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).
Comment 7 Murray McAllister 2009-03-25 06:10:12 EDT
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.
Comment 9 Jan Safranek 2009-03-25 07:17:11 EDT
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.
Comment 17 Tomas Hoger 2009-03-26 04:30:58 EDT
(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.
Comment 20 Tomas Hoger 2009-03-26 14:52:07 EDT
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.
Comment 23 Jan Safranek 2009-04-06 08:43:28 EDT
(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
Comment 26 Jan F. Chadima 2009-04-14 06:56:38 EDT
Will be fized in tcp_wrappers-7.6-55.fc11
Comment 28 Tomas Hoger 2009-04-16 07:45:04 EDT
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
Comment 29 Jan F. Chadima 2009-04-16 11:04:09 EDT
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.
Comment 30 Tomas Hoger 2009-04-16 12:13:10 EDT
(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.
Comment 31 Tomas Hoger 2009-04-22 09:44:08 EDT
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.
Comment 32 Jan Lieskovsky 2009-05-22 05:49:56 EDT
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.

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