Bug 465412 - Portmap reads /etc/hosts.{allow,deny} directly instead of using tcp_wrappers
Portmap reads /etc/hosts.{allow,deny} directly instead of using tcp_wrappers
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: portmap (Show other bugs)
5.2
All Linux
urgent Severity medium
: rc
: ---
Assigned To: Steve Dickson
BaseOS QE
: Reopened, Security
Depends On:
Blocks: 566705 668957
  Show dependency treegraph
 
Reported: 2008-10-03 02:52 EDT by Jan Hutař
Modified: 2011-10-15 21:26 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-15 21:26:05 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 Hutař 2008-10-03 02:52:11 EDT
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)
Comment 1 David Kovalsky 2008-10-03 04:54:24 EDT
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
Comment 3 RHEL Product and Program Management 2009-03-26 12:53:02 EDT
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 "?".
Comment 6 Tomas Hoger 2009-03-27 12:05:03 EDT
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.
Comment 7 Martin Poole 2009-08-19 09:58:17 EDT
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.
Comment 8 Tomas Hoger 2009-08-24 16:21:18 EDT
(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.
Comment 11 Jens Kuehnel 2010-02-10 16:05:39 EST
Do I understand it correctly, that this security bug (should be secure, but it's not) will not be fixed by RedHat?
Comment 12 Jan Lieskovsky 2010-02-13 09:35:21 EST
The Red Hat Security Response Team has rated this
issue as having low security impact, a future update
may address this flaw.
Comment 15 RHEL Product and Program Management 2010-12-07 05:29:44 EST
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.
Comment 16 Ludek Smid 2011-06-06 04:57:39 EDT
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.
Comment 23 David Mair 2011-10-15 21:26:05 EDT
Closing this issue as the original reporter has agreed to close given that RHEL6 and beyond will have a resolution for this issue.

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