NIS+ part 2: Not your father's name service Getting a grip on NIS+'s security features

October  1996

Adoption of NIS+ has been slow (to put it mildly). True, NIS+ was introduced poorly by Sun. The latest releases have turned it into a solid naming system that vastly improves security over NIS. This month we look at NIS+ and its security aspects.

Also in Pete's Wicked World this month: the bug-of-the-month-club describes the SYN attack and a solution, as well as two new sendmail bugs. And in the bookstore, an announcement of an interesting cryptography paper by Steve Bellovin, and an attack on the ACE/SecureID system and its rebuttal. (2,800 words)

Mail this article to a friend

Last month, I described how NIS+ can solve some of your security problems, and went into detail on the NIS+ authorization methods. These methods, which involve access control lists and fine-grain access right bits, provide a thorough method of protecting the information stored in the NIS+ domain. They allow the NIS+ administrator to decide, and to enforce decisions, regarding which users and groups can read, modify, create, and destroy entries and columns in the NIS+ tables.

Now it's time to explore the other half of the NIS+ security pie: authentication. Without authentication, NIS+ could not be sure of which users and groups it was granting access to. Further, NIS+ provides a reliable way of identifying users across network connections, allowing Unix features such as NFS and rlogin to be used in security-conscious environments. In such environments, the security weaknesses of those protocols are well known. For instance, without Secure-RPC (implemented as part of NIS+), NFS servers will grant filesystem access to any machine claiming to have an IP address in the server's export list. Likewise, rlogind will grant access to any user's account if the request comes from a system whose IP address is contained in /etc/hosts.equiv. Welcome to security, Berkeley style.

NIS+ solves these problems, and strongly authenticates every user in the NIS+ domain. It uses a combination if DES and Diffie-Hellman public-key encryption to assure itself that a user on a remote machine is really who he or she (or "it", as we shall see) claims to be.

Perhaps the most difficult part of understanding and using NIS+ is managing the terminology. First, a principal is a user on a NIS+ client, or the root user on the client workstation. In NIS+ terms, the root user on a client is referred to as a workstation. A principal is therefore a user or a workstation. A principal is authenticated to a NIS+ server before it can perform any operations on the NIS+ name space.

Each principal needs a credential to get authenticated. At login for a user or at request of service (i.e., an NFS mount request) for a workstation, the principal sends its credentials along with the request. There are two types of credentials: LOCAL and DES. You're used to LOCAL credentials, they are the UID of the principal -- the same credentials used for NIS and the r-commands (rsh, rlogin, etc). Because a workstation doesn't have a UID, LOCAL credentials only exist for users.

A DES credential is more complicated, because it is created and managed securely and is relatively unforgeable. The DES credential consists of two components:

• a secure RPC netname
• a verification field

The secure RPC netname takes the form unix.userid@domainname or unix.hostname@domainname. The verification field is to assure that the credential is unforgeable. A workstation principal's domainname is the string returned by the domainname command on that machine. For a user principal, the domainname is the name of the NIS+ domain that contains that principal's information.

NIS+ credentials are stored in the cred table of the NIS+ domain. This is a new table that, unlike most other NIS+ tables, does not correspond to an /etc file. The cred table has five fields:

1. Principal name: user or workstation
2. Authentication type: LOCAL or DES
3. First credential field
   • if LOCAL: UID
   • if DES: secure RPC Netname
4. Second credential field
   • if LOCAL: GID list
   • if DES: public key
5. if DES: encrypted private key

The actual creation of credentials, once you understand the theory and terminology, involves the straight-forward use of nisaddcred after the domain is established. nisaddcred creates either a LOCAL credential or a DES credential. To create a DES credential, nisaddcred creates the credential, and generates a public and private key. The public/private key pair is used to exchange the credential between the principal and server in a secure manner. If the credential was not secured for transmission, a network snoop could capture the credential and use it.

To generate the private key, nisaddcred uses the principal's network password. This network password starts as one provided to all users by the NIS+ administrator during NIS+ setup, but is usually changed by the user to be the user's login password. By doing so, the user only need login with one password, and the user both logs in to the workstation and gets NIS+ authenticated. Once this network password is provided, nisaddcred generates a public key and a private key that's encrypted with the network password. Both are stored in the cred table.

In order for a principal to be able to send its credential to the NIS+ server for authentication, it needs access to its private key. The principal executes a keylogin to gain this access. keylogin is done automatically if the principal's login password and network password are the same. The last step in creating a credential is generating the verification field. This is done using the NIS+ server's public key. Clients store this in their /var/nis/NIS_COLD_START file, along with other NIS+ cache information. Now the principal knows its own private key and can generate a credential for authentication.

An important and confusing point is that principal names always end with a period, while RPC netnames never do.

The final piece to the NIS+ security puzzle is the security level at which the NIS+ server runs. There are three levels:

• Security level 0 is used only when NIS+ is being installed. Credential checking is turned off.
• Security level 1 is the same as the security level of NIS. LOCAL credentials are used for all authentication.
• Security level 2 uses both LOCAL and DES credentials for authentication. This is the security level to use for day-to-day NIS+ operation.

Once the basics of NIS+ security are understood, it is a small step to setup and manage a NIS+ server, and to comprehend when to use keylogin and nisaddcred, how LOCAL credentials are used to support NIS+ domain hierarchies, and how and when to change public and private keys. For help along this path, be sure to have Rick Ramsey's excellent All about Administering NIS+ (second edition) at hand. I wouldn't touch NIS+ without it.

With the security aspects of NIS+ demystified, and with multiple vendors starting to provide support for NIS+, the popularity of NIS+ should grow. It's a powerful and secure facility for managing naming services in large environments.

Bug of the Month Club
By now you should know of the potent and unavoidable SYN attack that has been launched at the ISP PANIX and other sites. The attack is powerful in its simplicity and insidious because it is difficult to repel. It takes advantage of TCP's connection-establishment protocol. Essentially, it ties up a server with continuous half-open connections, leaving no resources to complete connections to client programs. Full details are available via the CERT advisory 96.21

The company ISS has released an alpha-test version of RealSecure, a tool that can help solve SYN attacks. Here is an extract from the firm's announcement:

Another way to fix this is to set the kernel maximum number of half
open connections allowed (SO_MAXCONN) to a higher number than the
default value. We have a tool that will look for SYN packets that do
not get followed with ACK and clean the half open connections by
sending a RST packet.  This unclogs the port and allows legitimate
connections to happen.  This tool is called RealSecure (tm).  To
obtain a copy of the RealSecure tool, send e-mail to "majordomo@Iss.net"
and within the body of the message, type: 

	subscribe realsecure

RealSecure (tm) is a comprehensive attack recognition and real time
response tool that ISS is alpha testing and will expire in 60 days.

If it seems like I'm repeating myself, it's because I am. sendmail has two new security holes that should be fixed immediately. These bugs are in all versions of sendmail up-to and including 8.7.5. The first bug allows a system user to become the user-id of the sendmail default user (typically "daemon"). This bug is caused when sendmail is starved of the resources needed to resolve the name of the owner of a .forward or .vacation file. The other bug, which allows a local user to gain root access on a system, is caused by sendmail allowing the overwriting of buffers. Both bugs are detailed in CERT Advisory CA-96.20. The bugs are fixed in sendmail.8.7.6. CERT is also making available a list of latest software versions to help you be sure that all your software is the latest release.

The CERT advisory also provides solid advice for helping to secure sendmail, no matter what release you are running. Of course it is important to keep up with the bug fixes and be sure the latest version is installed, but some other steps worth implementing include:

• Run sendmail with the sendmail restricted shell smrsh, so even if a user escapes from sendmail the potential damage is limited.
• Always run the latest version of sendmail, and delete old versions.
• Replace /bin/mail with /bin/mail.local. mail.local is included in the sendmail release and helps prevent exploitation of some sendmail bugs.

A final thought on sendmail: beware most firewalls. For most firewalls, SMTP protocol is allowed through to enable exchanges of mail via the Internet. Most firewalls, especially those that are packet-filter based, simply pass SMTP through, unimpeded. sendmail bugs can be exploited even though a firewall generally protects your systems. Some firewalls, notably the proxy-gateway based Raptor and TIS Gauntlet, filter the actual SMTP stream and disable SMTP protocol commands that are extraneous or that can be used to attack sendmail installations. These firewalls can protect even your SMTP server from attacks.

A bug of more limited impact involves the Transarc DFS implementation on Solaris. (DFS is a sophisticated, reliable, and secure distributed filesystem. It's part of DCE.) A user placed in too many groups (generally more than 15) will have the wrong group list at login time. For details, see the CERT advisory.

The bookstore
Last month's column held a rumor of a paper describing attacks on the ACE/SecureID system being published. Well, the whitepaper by PeiterZ is out, and is available at ftp.secnet.com. After reading that, you may want to read the rebuttal from Security Dynamics.

Being a security consultant can make you very cynical. For one veteran's entertaining views on the state of the war, check out these slides from a talk.

A few months ago, World Star Holdings issued a challenge to the hacker community, asking that their firewall be attacked. Regardless of the merits of such a challenge and the results of the ensuing attacks, the information gleaned by the attackers makes interesting reading.

Steve Bellovin has announced the release of a paper that should be interesting to those with a cryptography bent. Here's his description:

Folks on this mailing list may be interested in a new draft paper of mine:

Probable Plaintext Cryptanalysis of the IP Security Protocols

The Internet Engineering Task Force (IETF) is in the process of adopting standards for IP-layer encryption and authentication (IPSEC). We describe how ``probable plaintext'' can be used to aid in cryptanalytic attacks, and analyze the protocol to show how much probable plaintext is available. We also show how traffic analysis is a powerful aid to the cryptanalyst. We conclude by outlining some likely changes to the underlying protocols that may strengthen them against these attacks.

It's available from research.att.com.

The mailbox
Thanks to Dan Stromberg for this note about a more intelligent yppasswd available for Solaris:

Date sent:        Sat, 14 Sep 1996 16:18:34 -0700
From:             strombrg@hydra.acs.uci.edu (Dan Stromberg)
To:               peter.galvin@wpi.com
Subject:          preventing poor password choices

For what it's worth, I've ported the Linux yppasswd to Solaris, Irix 
and OSF/1. 

I tossed in a very light-weight password check, based on
the "common triples" thing in English-like languages: only
a small percentage of all three character sequences are used;
the program ensures that a minimal number of three
characters outside this common set are chosen.

It's at ftp://autoinst.acs.uci.edu/pub/yppasswd.tar.gz.

I gave my changes back to the maintainer of the upstream sources.
I gather he's merged the changes.

I did not stress-test the shadow passwords at all, nor did
I test "normal" local passwords.  I've been pushing NIS,
and didn't bother examining local-only accounts.

Next month we'll unveil an invaluable tool: the Solaris Security FAQ

Resources

• "NIS+ part 1: 1: What's in a Name (Service)?"
  /sunworldonline/swol-09-1996/swol-09-security.html
• CERT advisory on TCP SYN attacks
  ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
• ISS's alpha-test RealSecure
  http://www.iss.net/
• CERT Advisory CA-96.20 on more sendmail bugs
  ftp://info.cert.org/pub/cert_advisories/CA-96.20.sendmail_vul sendmail v. 8.7.6 ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz
• CERT's list of latest software versions
  ftp://info.cert.org/pub/latest_sw_versions
• CERT advisory on Transarc DFS
  ftp://info.cert.org/pub/cert_bulletins/VB-96.16.transarc
• Paper describing attacks on the ACE/SecureID system
  ftp://ftp.secnet.com/pub/papers/securid.ps
• rebuttal from Security Dynamics
  http://www.securid.com/ID271.132026525807/Resources/WhitePapers/2897.html
• cynical slides from a security talk
  http://www.v-one.com/pubs/naked/index.html
• Results of World Star Holdings firewall challenge
  http://www.cs.cuc.edu/~sopwith/comp-security/ws.html
• Bellovin white paper
  ftp://ftp.research.att.com/dist/smb/probtxt.ps
• more intelligent yppasswd
  ftp://autoinst.acs.uci.edu/pub/yppasswd.tar.gz
• Earlier Security
  /sunworldonline/common/swol-backissues-columns.html#security

About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a Systems Integrator and VAR. He is also Adjunct System Planner for the Computer Science Department at Brown University, a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at peter.galvin@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-10-1996/swol-10-security.html
Last modified: