good_client() function is portmap, which uses tcp_wrapper, is affected by the flaws previously described for the same function in nfs-utils: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-4552#c8 With certain hosts.{allow,deny} rules, expected host access control restrictions may not be applied correctly. The problem does not affect configurations that has deny:ALL and only allow access for specific hosts / networks. Additionally, portmap in Red Hat Enterprise Linux 3, 4 and 5 statically links libwrap.
In addition to problems described by Tomas Hoger above, as well as problems outlined in CVE-2008-4552, in some configurations the faulty code in good_client() has yet another effect that may cause portmap to become unresponsive. This happens under different conditions and does affect configurations that deny ALL. Details: In the case when tcp-wrappers are used to authorize access to the NIS server which is used for hostname resolution on the same machine (as would be typical for a slave NIS server), the code in good_client() will cause a recursive request to portmap, causing portmap to deadlock and the NIS server to become unresponsive. This is occurring even when hosts.allow and hosts.deny do not contain any hostnames, as in such case portmap will perform a hostname resolution even though it is not necessary. TCP-wrappers contain logic which resolves hostnames only when needed. Thus the fix provided in CVE-2008-4552 solves this issue as well. With the fix, the deadlock will still happen, but only when hostnames are used in portmap rules in hosts.allow or hosts.deny. (The deadlock issue could be completely solved if authorization were moved away from the non-reentrant section of portmap's request handler, allowing it to handle recursive requests, but such a modification is out of scope of this report.)
(In reply to comment #1) > Details: In the case when tcp-wrappers are used to authorize access to the NIS > server which is used for hostname resolution on the same machine (as would be > typical for a slave NIS server), the code in good_client() will cause a > recursive request to portmap, causing portmap to deadlock and the NIS server to > become unresponsive. This is occurring even when hosts.allow and hosts.deny do > not contain any hostnames, as in such case portmap will perform a hostname > resolution even though it is not necessary. Yes, the risk of such infinite recursion in name resolution was pointed out in some discussions of this/related issue. If you want this addressed in some specific RHEL version, please get in touch with Red Hat Support, so the request can get prioritized properly for inclusion in the future updates.
I do not use RHEL and I have fixed portmap on my systems by patching the code and rebuilding the rpm. The time and effort I have put in submitting bug reports and comments regarding this issue was motivated by a wish, perhaps naive, to participate in the betterment of free and open software. Small correction regarding the matter of infinite recursion: In the typical configuration the recursion is only one-level. The recursive request to portmap comes from localhost, which would be resolved by looking up /etc/hosts file, without triggering further recursive hostname lookups. The deadlock occurs because client authorization is done in the same process/thread as the one that listens for incoming requests. This is a design flaw in portmap, a separate problem from the one being discussed in this bug report.
I have been running with forked portmap package (patched as described in CVE-2008-4552) on two production servers since 2010, with no problems. I am curious, is this patch ever going to be applied to the package available in the repos? We have here a piece of code that was released untested, introducing a glaring security hole that went unpatched for years, despite the fact that we knew what was wrong and we had a fix (a straightforward one, may I add).
I have decommissioned my last CentOS 5 server, and I won't be able to provide any more help on this issue. If someone comes here looking for a solution to this problem, my suggestion is to avoid using hosts.deny and hosts.allow, and to apply protection by means of iptables instead. However, given the fact that portmap suffers from poor code quality and is apparently abandoned, I suggest switching to another distribution that uses rpcbind in place of portmap.