Bug 491095 (CVE-2009-0786)
Summary: | CVE-2009-0786 tcp_wrappers: hosts_ctl() does not handle hostnames specified in /etc/hosts.{allow,deny} correctly | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Jan Lieskovsky <jlieskov> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | jchadima, jsafrane, jscotka, kreilly, mkoci, mmcallis, security-response-team, tao, yersinia.spiros |
Target Milestone: | --- | Keywords: | Reopened, Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-04-22 13:44:08 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: | 489703, 489705, 491106, 491107 | ||
Bug Blocks: |
Description
Jan Lieskovsky
2009-03-19 13:27:48 UTC
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. |