portmap Forwarding

The portmap program forwards mount requests to the rpc.mountd and causes them to appear to originate from the IP address of the system running portmap. This eliminates IP source restrictions on NFS servers from taking effect. SATAN does a scan for this portmap vulnerability.

World-Writeable Mail Directory and Links

When the /var/mail directory is world-writeable, any user can create a file in that directory. If a user created a link from a username to an outside file, sendmail’s delivery agent, such as /bin/rmail, would write the incoming mail file to the linked file. Imagine if a user created a link from /var/mail/root to /etc/passwd. The user could then mail a new username to root and have it appended to /etc/passwd. The /var/mail directory should never be world-writeable.

NFS uid 16-Bit Problem

An NFS server depends on client-side authentication, verifying only the source IP address of the request, so claiming to fix an NFS server vulnerability is a tenuous claim at best. In general, root access to files on an NFS server require an explicit statement in the exports file; otherwise, root client requests have their uid mapped to –2 (nobody), which restricts their access to world-accessible files.

However, a user that claimed a client uid of 0 + 2^16 = 65536 would be acceptable to NFS and not get remapped to a new uid. When that user requested access to a root-owned file, the comparison of uids would use only the lower 16 bits of the uid, allowing this user to masquerade as root.

arp -f Problem

The arp program uses an -f flag to permit a user to specify a file containing an arp cache to be read. If that file is in an unacceptable format, arp prints out the contents as an aid for debugging. This means that a regular user can read any root-owned file on the system by specifying that file to arp using the -f option.

sendmail -C Problem

sendmail permits the user to specify a configuration file. Because any user can invoke sendmail (this is required to be able to send mail), and because sendmail does a set-uid to root, this means that sendmail can read any root-owned file. The vulnerability was that if the file specified was an unacceptable choice, sendmail would print the contents out as an aid for debugging. This meant that a regular user could read any root-owned file on the system by specifying that file to sendmail using the -C option.

rwall Writing Problem

A user could create an entry into the utmp file of current users that really represented a filename. Then invoking rwall to send a message to all users would result in that message being written to that file. A new /etc/passwd file or a /.rhosts file could be written by using the appropriate message. This problem was a result of the fact that the utmp file could be modified by a regular user.

---

Note:  Advice to designers: Notice that several of the security holes are based on the same common mistakes. Programs that avoid range checking on strings or values that can be passed in by the remote user (syslog, fingerd, sendmail debug), resulting in the stack frame being overwritten are continually being found. Programs that have higher privileges and can manipulate files, by either reading and printing them out or writing them and allowing a user to specify the pathname (write the log to /etc/passwd) or to create a link from the standard pathname, are frequently seen. Client-side authentication is not acceptable, yet many programs continue to think that if a system administrator on the client system approves authentication, security is maintained—surprisingly, many hackers double as system administrators for their systems. Finally, security that depends solely on hostname or IP authentication can be easily circumvented.

---

Learning About New Security Holes

SATAN is distributed with scans for only a handful of vulnerabilities. Granted, the vulnerabilities that SATAN scans for are quite widespread and severe in nature; however, SATAN provides a wonderful framework for easily adding scans for new security holes. A vigilant system administrator can easily add new scans (demonstrated later in this chapter), if he or she knows about new security holes.

The Internet is a wonderful place to find out about new security holes. Network news, mailing lists, web sites, FTP archives, and vendor patches all help to identify new security issues. The section at the end of the chapter contains a detailed list of network sites and mailing lists.

The best place to start is with the network newsgroups. Although new groups are always being created, a core set of useful groups can always be depended upon: comp.security.unix, comp.security.misc, and alt.security are the primary groups that deal with security. A few others, such as comp.security.firewalls, comp.security.announce, alt.2600, and sci.crypt, are occasionally useful, although these groups contain quite a bit of theory or noise. Although books and papers can provide you with a good basis for understanding security, it is a rapidly developing field, and the newsgroups are the latest source for updates.

Mailing lists are quite useful, although they can generate quite a bit of uninteresting traffic. A popular list is bugtraq mailing list (network security holes) bugtraq, which has continuing discussions about new vulnerabilities and security topics. The CIAC, CERT, and vendor lists are useful in announcing the availability of new patches to address security holes; they rarely announce the presence of holes that are not yet fixed.

Other non-security-related mailing lists that directly address Internet services also frequently deal with security. Mailing lists for sendmail, bind, SSL, Kerberos, e-payments, ipk (public key infrastructure), ietf-822, drums (e-mail), and IETF working groups all offer useful tidbits, although the volume on each is quite high compared to the number of security-related issues.

The advent of the World Wide Web has resulted in the creation of many web pages dedicated to security. Some of the best include the U.S. DOE’s CIAC web site and the Purdue University COAST project site. A list of web sites is included in Appendix B, “Internet Security References.”

Reverse engineering patches from vendors that have catalog descriptions indicating security problems can always be informative. Perhaps the other vendors have yet to fix this problem, or perhaps the other OS platforms are not yet patched?