Description of problem: When I disable some clinet using /etc/hosts.deny and clients IP, portmap still responds. When I use 'ALL' (and not client's IP), client stops responding. Version-Release number of selected component (if applicable): Server (RHEL-5.2, 192.168.122.245): glibc-common-2.5-24.i386 portmap-4.0-65.2.2.1.i386 tcp_wrappers-7.6-40.4.el5.i386 ClientA (F8 mostly GOLD, 192.168.122.97): rpcbind-0.1.4-11.fc8 ClientB (F9 updated, 192.168.122.1) rpcbind-0.1.4-16.fc9.x86_64 How reproducible: always (with steps below) Steps to Reproduce: 1. Server runs portmap Server# service portmap status portmap (pid 20540) is running... 2. Server# cat /etc/hosts.allow # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # 3. Server# cat /etc/hosts.deny # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! 4. ClientA# rpcinfo 192.168.122.245 program version netid address service owner 100000 2 tcp 0.0.0.0.0.111 portmapper unknown 100000 2 udp 0.0.0.0.0.111 portmapper unknown 5. ClientB# rpcinfo 192.168.122.245 program version netid address service owner 100000 2 tcp 0.0.0.0.0.111 portmapper unknown 100000 2 udp 0.0.0.0.0.111 portmapper unknown 6. Server# echo "portmap: 192.168.122.97" >> /etc/hosts.deny Server# echo "portmap: 192.168.122.1" >> /etc/hosts.deny 7. ClientA# rpcinfo 192.168.122.245 program version netid address service owner 100000 2 tcp 0.0.0.0.0.111 portmapper unknown 100000 2 udp 0.0.0.0.0.111 portmapper unknown 8. ClientB# rpcinfo 192.168.122.245 No remote programs registered. 9. Server# echo "portmap: ALL" >> /etc/hosts.deny 10. ClientA# rpcinfo 192.168.122.245 No remote programs registered. 11. ClientB# rpcinfo 192.168.122.245 No remote programs registered. Actual results: See point "7." Expected results: Point "7." should be same as point "8." Additional info: These systems used for testing are on virtual netvork created by virt-manager. ClientB: host (192.168.122.1) ClientA: guest (192.168.122.97) Server: guest (192.168.122.245)
Looking at the problem it seems to be due to the fact that portmap doesn't link libwrap, but reads /etc/hosts.{allow,deny} directly. Haven't checked the sources yet, though. [Changing the topic a bit to reflect the real issue] .live.[root@i386-5c-2-m1 ~]# strings /sbin/portmap |grep hosts hosts_access_verbose hosts_allow_table hosts_deny_table /etc/hosts.allow /etc/hosts.deny .live.[root@i386-5c-2-m1 ~]# ldd /sbin/portmap linux-gate.so.1 => (0x00925000) libnsl.so.1 => /lib/libnsl.so.1 (0x004b2000) libc.so.6 => /lib/libc.so.6 (0x00ae8000) /lib/ld-linux.so.2 (0x00714000) Is there a reason to re-implement tcp_wrapper's work? Maybe because libwrap libs are under /usr in RHEL5? [They are in /lib under F8] [dkovalsk@f8 ~]$ locate libwrap /lib/libwrap.so.0 /lib/libwrap.so.0.7.6 .live.[root@i386-5c-2-m1 ~]# locate libwrap /usr/lib/libwrap.a /usr/lib/libwrap.so /usr/lib/libwrap.so.0 /usr/lib/libwrap.so.0.7.6
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Portmap *does* use tcp_wrappers / libwrap, but links it statically, not dynamically, as was previously mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-4552#c3 Additionally, the way portmap uses tcp_wrappers is incorrect (same problem as with nfs-utils mentioned in the bug referenced above), so the rules you specify may or may not work as expected. From a quick look, rules using IPs or ALL wildcard are likely to work, rules using hostnames should not work.
It appears that portmap does not use the hosts.* files in a sane manner. Pure IP in deny does not work unless the corresponding hostname entry is also present. The following are variation in hosts.deny ALL: host-46.example.com [root@host-46 ~]# rpcinfo -p sat52-64 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper ALL: 192.168.69.32/255.255.255.224 [root@host-46 ~]# rpcinfo -p sat52-64 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper ALL: host-46.example.com ALL: 192.168.69.32/255.255.255.224 [root@host-46 ~]# rpcinfo -p sat52-64 No remote programs registered. I've fiddled with using STRING_UNKNOWN / "unknown" in the good_client() routine call to hosts_ctl() which did change the result as it drops through to the local name checking code. Reducing the good_client() routine to just a call hosts_ctl and return its result produces a version that will block on just IP in the file, but also works if just hostname which would seem to be contrary to the upstream comments regarding name lookups for this UDP service.
(In reply to comment #7) > It appears that portmap does not use the hosts.* files in a sane manner. > > Pure IP in deny does not work unless the corresponding hostname entry is also > present. Yes, makes sense looking at what good_client() does. It calls hosts_ctl multiple times, for IP, host name and all aliases. Access is allowed if hosts_ctl allows access for any of that. Obviously not really common or expected way to use tcp_wrappers. Reasons why it was added can be understood too, but it's probably not too good from consistency point of view. > Reducing the good_client() routine to just a call hosts_ctl and return its > result produces a version that will block on just IP in the file, but also > works if just hostname which would seem to be contrary to the upstream comments > regarding name lookups for this UDP service. hosts_ctl does not do IP -> host name resolving in upstream tcp_wrappers, that is only added by RHEL/Fedora specific patch, which is frowned upon by upstream. Proper fix should probably use hosts_access instead, which can be used even in a way that would avoid name resolution. Anyway, it's probably safer to use "<service>: ALL" rule in hosts.deny and use IP based rules to allow access from all hosts that need access.
Do I understand it correctly, that this security bug (should be secure, but it's not) will not be fixed by RedHat?
The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.6 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
Closing this issue as the original reporter has agreed to close given that RHEL6 and beyond will have a resolution for this issue.