Bug 21252 – Portmap not actually wrapped?

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 21252 - Portmap not actually wrapped?

Summary:	Portmap not actually wrapped?

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	portmap (Show other bugs)
Sub Component:
Version:	6.2
Hardware:	i386 Linux

Priority	high Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Trond Eivind Glomsrxd
QA Contact:	Aaron Brown
Docs Contact:

URL:
Whiteboard:
Keywords:	Security

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2000-11-22 12:22 EST by jon
Modified:	2007-03-26 23:37 EDT (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2000-11-23 06:15:17 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description jon 2000-11-22 12:22:04 EST

System has all current updates installed.

/etc/hosts.deny is as follows:
-----------
#
# 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!

ALL: ALL

# portmap: ALL: (/usr/sbin/safe_finger -l @%h | mail root) &
------------
(Note that portmap line is commented out but should be caught by ALL: ALL)

/etc/hosts.allow is as follows:
---------------------
#
# 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.
#

sshd: ALL
------------------------

tcpdmatch reports that portmap should be blocked:

[root@chimay jon]# tcpdmatch portmap gwyn.tux.org
warning: portmap: service possibly not wrapped
client:   hostname gwyn.tux.org
client:   address  207.96.122.8
server:   process  portmap
matched:  /etc/hosts.deny line 10
access:   denied
-------------------------------------

But from that same test address:

[lasser@gwyn lasser]$ telnet chimay.skynetweb.com 111
Trying 64.23.4.67...
Connected to chimay.skynetweb.com.
Escape character is '^]'.


Sure looks live to me.

The service name portmap is per the documentation, but it sure looks like
it should be blocked, right? It's possible I'm doing something wrong, but
this looks bad to me...

Comment 1 Jarno Huuskonen 2000-11-23 02:24:16 EST

I did some testing with this config (RH6.2 with all updates):
/etc/hosts.deny
ALL:ALL

and empty /etc/hosts.allow

Portmap still allows rpcinfo from localhost, but not from remote hosts.
And tcp connections are not wrapped at all ( I can connect to port 
111 from anywhere).

This appears to be a bug in portmap.

Comment 2 Jarno Huuskonen 2000-11-23 06:15:15 EST

After looking thru portmap source I noticed that hosts_ctl is called only
if the request comes from a remote address. Here's part of the code:
#ifdef HOSTS_ACCESS
    if (!(from_local(addr) || good_client(addr))) {
  log_bad_host(addr, proc, prog);
These kind of checks are in several places in pmap_check.c

One possible fix for this would be to remove from_local(addr) call from 
the if statement (and then remember to add localhost to hosts.allow).

Also I think that the tcp_wrapper checks are called only if portmap gets
a valid rpc-call --> anyone can still connect to port 111 with telnet and
possibly 'consume' filedescriptors. Could someone do a more thorough testing
of this issue ?

Also one more thing: Portmapper calls setuid(1) w/out calling setgid earlier
so it's running as uid=1 gid=0 <- root gid. Is there a reason for this ?

Comment 3 Trond Eivind Glomsrxd 2001-01-20 19:32:01 EST

I think I'll keep it the way the authors intended... turning it off (and not
allowing localhost) would break things needing it, like nfslock, yp etc. Thanks
for the input.

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