SUMMARY: Need a secure 'portmap' daemon - NIS security questions...

From: Joel L. Seber - Sun Workstation Lab Manager (JLS2013@tntech.edu)
Date: Fri Feb 09 1996 - 14:17:55 CST


Thanks to everyone who responded! I include here my original question, the
partial summary I posted a few days ago, and the resolution to the
additional question posted in the partial summary, along with any other
relevant information.

ORIGINAL QUESTION:

>OS: SUNOS-4.1.3_U1
>Platforms: Sparc 1,1+,2,IPC,Classic
>Issues: Security, NIS
>
>After looking through the various FAQs, manuals, and patch summaries, I put
>it to the list: does anyone know of a secure implementation of 'portmap'
>that would disallow a system from outside your network from tapping your
>domain and garnering such items as NIS maps? I need to be able to allow
>access to designated remote machines outside my subnet structure while
>denying all others.

PARTIAL SUMMARY:

>A followup to my earlier posting concerning a secure portmap daemon: Sun
>had a patch to address this (100482) for OSes up through 4.1.3. They
>applied this patch to 4.1.3_U1 (along with many others) and it solved my
>problem. You basically have to create a file called /var/yp/securenets with
>one or more lines of the format
>
>netmask netaddr
>
>e.g.
>
>255.255.0.0 128.30.0.0
>255.255.255.0 128.311.10.0
>
>The second example allows ypserv to respond only to those addresses within
>the subnet 128.311.10 range. You can have as many as you need ( as far as
>I know ).
>
>One additional question is raised by this: is it possible to address only
>one machine out of a subnet with this procedure? It would help me quite a
>bit if it were possible. Any suggestions are welcome!

And the answer to the question above:

Using a netmask of 255.255.255.255 allows you to reference any one computer.
E.g.,

255.255.255.255 132.19.205.4

would reference just that host. (The address above was changed to protect
the innocent. :-) )

Finally, sections of relevant comments on these questions:

Joel,

        I ran across a CERT advisory a few minutes ago that might pertain to
your systems. It's kinda old, but does address some SunOS NIS problems.
 I don't know if it'll help you any or not, but here it is:

--Duane

--Cut here----

CA-92:13 CERT Advisory
                               June 4, 1992
                          SunOS NIS Vulnerability
-------------------------------------------------------------------------=

--

The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning several vulnerabilities with NIS under Sun Microsystems, Inc. SunOS. These vulnerabilities exist in NIS under SunOS 4.1, 4.1.1, and 4.1.2, and may or may not exist in earlier = versions of NIS.

Sun has provided fixes for SunOS 4.1, 4.1.1, and 4.1.2 for these vulnerabilities. The patch file containing these fixes is available through your local Sun Answer Center and through anonymous ftp from ftp.uu.net (137.39.1.9) in the /systems/sun/sun-dist directory. Note that these fixes will probably not be compatible with SunOS 4.0.3 and earlier versions of the operating system.

Fix PatchID Filename = Checksum /usr/etc/{ypserv,ypxfrd,portmap} 100482-2 100482-02.tar.Z 53416 = 284

Please note that Sun will occasionally update patch files. If you find that the checksum is different, please contact Sun or the CERT/CC for verification.

-------------------------------------------------------------------------= --

I. Description

A security vulnerability exists under NIS allowing unauthorized = access to NIS information.

II. Impact

A user on a remote host can obtain copies of the NIS maps from a system running NIS. The remote user can attempt to guess passwords for the system using the obtained NIS password map information.

III. Solution

A. Obtain and install the patch from Sun or from ftp.uu.net = following the instructions provided in the "README" file. =20

1. As root, rename the existing versions of /usr/etc/{ypserv,ypxfrd,portmap} and modify the permissions to prevent misuse.

# mv /usr/etc/ypserv /usr/etc/ypserv.orig # mv /usr/etc/ypxfrd /usr/etc/ypxfrd.orig # mv /usr/etc/portmap /usr/etc/portmap.orig # chmod 0400 /usr/etc/ypserv.orig=20 # chmod 0400 /usr/etc/ypxfrd.orig # chmod 0400 /usr/etc/portmap.orig

2. Copy the new binaries into the /usr/etc directory.

# cp `arch`/{4.1, 4.1.1, 4.1.2}/ypserv /usr/etc/ypserv # cp `arch`/{4.1, 4.1.1, 4.1.2}/ypxfrd /usr/etc/ypxfrd # cp `arch`/{4.1, 4.1.1, 4.1.2}/portmap /usr/etc/portmap # chown root /usr/etc/ypserv /usr/etc/ypxfrd = /usr/etc/portmap # chmod 755 /usr/etc/ypserv /usr/etc/ypxfrd = /usr/etc/portmap

3. Copy the securenets file to the /var/yp directory. Any site that has an existing /var/yp/securenets file should=20 rename it prior copying the new version of the file.

# cp `arch`/{4.1, 4.1.1, 4.1.2}/securenets /var/yp # chown root /var/yp/securenets # chmod 644 /var/yp/securenets

4. Edit the /var/yp/securenets file to reflect the correct configuration for your site. See the "README" file for details of the file syntax and special instructions for hosts with multiple Ethernet interfaces. The file should not contain any blank lines. =20 5. Reboot the system to invoke the new binaries.

-------------------------------------------------------------------------= -- The CERT/CC would like to thank Casper Dik of the University of = Amsterdam, The Netherlands, and Peter Lamb of the Division of Information = Technology, Commonwealth Scientific and Industrial Research Organization, Australia, for their assistance. We also wish to thank Sun Microsystems, Inc. for their response to this vulnerability. -------------------------------------------------------------------------= --

If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security = Teams).

Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. = EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.org (192.88.209.5).

==============================

The mask 255.255.255.255 means to match the entire address. 0-bits in the mask are "don't care", and this has no 0-bits.

-- Barry Margolin BBN PlaNET Corporation, Cambridge, MA barmar@bbnplanet.com Phone (617) 873-3126 - Fax (617) 873-6351

==============================

secure portmap is at ftp.win.tue.nl in one of the security dirs.

weitze is the administrator of that location, he is the person that wrote tcp wrappers fyi

--chris

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Christopher Eastman %% Cable & Wireless, Inc %% %% MDS Network Engineer %% 1919 Gallows Road %% %% chris@cwi.net %% Vienna, VA 22182 %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

==============================

ftp to ftp.win.tue.nl in pub/security, for wieste venemas secure rpcbind. It ''authenticates'' like tcpwrappers...

Jim

--- Jim McBride jmcbride@neog.com Neoglyphics Media Corp. http://www.neog.com

=================================

Yes, use Wietse Venema's rpcbind, which can be found at: ftp://ftp.win.tue.nl/pub/security/rpcbind_1.1.tar.Z

Regards,

John -- John DiMarco <jdd@cdf.toronto.edu> Office: EA201B Computing Disciplines Facility Systems Manager Phone: 416-978-1928 University of Toronto Fax: 416-978-1931 http://www.cdf.toronto.edu/personal/jdd/jdd.html

===================================

We use

ftp.cert.org:/pub/tools/nfs_tools/portmap_3.shar.gz

on machines with Solaris and

ftp.cert.org:/pub/tools/nfs_tools/rpcbind_1.1.tar.gz

on SunOS 4.1.3...

Both tools are replacements for daemons shipped with operating system. They work in conjunction with tcp_wrapper library:

ftp.cert.org:/pub/tools/tcp_wrappers

Best regards,

Benjamin Zwittnig

--

---------------------------------------------------------------------------- Benjamin Zwittnig phone: +386 61 125 15 15 ARNES fax: +386 61 125 54 54 (Academic and Research Network of Slovenia) Jamova 39 61111 Ljubljana e-mail: Benjamin.Zwittnig@arnes.si Slovenia C=si;ADMD=mail;PRMD=ac;S=Zwittnig;G=Benjamin ----------------------------------------------------------------------------

============================

yes portmap_3 from Wietse Venema will do just what you are looking for! here is the BLURB:

This is the third replacement portmapper release.

There is an increasing interest in access control for the NIS, mount and other RPC-based services that are normally registered with the portmap process. Possible attacks on RPC daemons involve:

- theft of NIS (YP) password files

- ypset to force hosts to bind to a rogue NIS (YP) server

- theft of NFS file handles

My contribution is a replacement portmap program, derived from source code in the RPCSRC 4.0 and the TIRPC source distributions. Access control is in the style of my tcp wrapper (log_tcp) package. It should

work with all SunOS 4.x and Ultrix >= 3.0 releases. However, the source is reasonably portable and the code should work on most UNIX systems that provide SUNRPC on top of BSD-style TCP/IP. System V.4 support is problematic, though.

The present portmap version attempts to close all portmap security problems that are known to me. It should be as secure as the portmap daemon that comes with the SunOS 4.x portmap+NIS patch (patch id 100482-02). The README file gives a complete list of security features.

Without the availability of portmap source, possible alternatives are 1) packet filtering with a smart router; 2) linking the portmap executable against the securelib shared library. Linking RPC daemons against the securelib library is a good idea, anyway.

The source is available for anonymous FTP from ftp.win.tue.nl directory /pub/security/portmap_*.shar.Z.

Wietse Venema (wietse@wzv.win.tue.nl) Mathematics and Computing Science Eindhoven University of Technology The Netherlands

-- Ciao! Shakeel

******************************************************** __ *************** Hewlett-Packard(Canada) Ltd. ************* / / ************ Panacom Division(PAD) *********** / / ********* 20 Lexington Road ********* / /___ ______ ******* Waterloo, Ontario ******** / __ // __ / ****** Canada N2J 3Z3 ******** / / / // /_/ / ****** Email: rao@waterloo.hp.com ********* /_/ /_// ____/ ******* Phone : (519)883-3089 ********** / / ********* Fax : (519)886-8620 ************ / / *********** ***************************************************** /_/ ****************

==========================

Thanks to all the above and those with 'me too' replies. Moral support is also important when problems are occurring!

Regards,

Joel L. Seber | Dry humor is wasted around here. Sun Workstation Laboratory Manager | -Joel L. Seber Center for Manufacturing Research | and Technology Utilization | recursive, adj. Tennessee Technological University | See 'recursive' Box 5077 Brown Hall | Cookeville, TN 38505 | What if there were no hypothetical jls2013@tntech.edu | situations? -Steven Wright more info: | finger jls2013@gemini.tntech.edu | Who, me? -Alfred E. Newman | | "It is bad luck to be superstitious." | -- Andrew W. Mathis



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:53 CDT