Billions and billions of bugs What security bugs could effect you? And how can you stomp them out?

March  1996

Reports of bugs that affect Solaris systems are coming fast and furious. How can you keep up? Which bugs should you care about? And how can you find the appropriate fixes? This month we survey the current bugs and their solutions. We also take a look at common break-in methods and what can be done to be sure hackers leave your site alone. The basis for our bug-walk is Sun's security cookbook.

Also in Pete's Wicked World this month: a serious bug involving the bind DNS daemon, a jumbo patch for NSKIT V1.2, and a nasty denial-of-service attack to avoid. In the bookstore you'll find a pointer to a nice comparison of network security scanning software. (1,900 words)

Mail this article to a friend

Billions and billions of bugs inhabit the earth. Fortunately, most of them stay out of your way. Unfortunately, there are some nasty ones among those that remain. You need to keep an eye on them, and try to stomp them when you get the chance. This is also the case with computer bugs -- they, too, are plentiful, and the nasty ones need to be stomped when encountered. The right pair of boots (in the form of a patch) will help with this task.

Sun has put together a nice collection of security wisdom relating to SunOS and Solaris. Unfortunately, this security cookbook, in the form of a SunSolve Online Security bulletin, is incomplete. We'll review Sun's advice (Solaris only) and fill in the gaps with some lesser-known security hints. In the Bug-of-the-Month club, we continue the discussion with several new, important bugs that currently lack Sun patches.

The security cookbook

• Install all applicable security patches. The best way keep up to date, aside from (shameless plug) reading this column, is to check out the Sun patch list. Unfortunately, Sun makes only "recommended" patches available, unless you have a Sun support contract. Nevertheless, There are more than two dozen important system and security patches for Solaris 2.4 currently available. Generally, it is safe to install recommended patches even if you are not experiencing the problem described -- Sun tests these patches thoroughly. And some good news: Solaris 2.5 has no recommended patches, and only one security patch (a vipw bug).

• Require single-user boot password, and disable remote root login, by making sure that the line CONSOLE=/dev/console is in /etc/default/login. Also, disable root ftp by putting "root" into /etc/ftpusers. (This should actually be called ftplusers because it lists users that can't ftp into the system.)

• Trust no-one, or at least very few, by limiting the contents of /.rhosts, /etc/hosts.equiv, and ~/.rhosts. Also, consider installing tcp_wrapper or other protection software to log connection activity and limit possible access.

• Keep root's path to a minimum. Don't include the current directory (.) in it. As a side benefit, this makes working as root inconvenient, encouraging systems staff to do their root thing and exit, rather than lingering as root (and risking system penetration).

• NIS servers should not use NIS for password information, they should use "files" instead. Solaris NIS clients can and should bind directly to an NIS server, rather than broadcasting form one. See ypinit -c. Additionally, the NIS password table should be built from a non-/etc directory that has a passwd file with the system directory accounts removed (so they aren't provided to clients by NIS).

• Remove the decode mail alias in /etc/aliases. Set permissions of /etc/aliases to 644 and owned by root. Be sure to read about the newest sendmail bugs, and consider running Berkeley sendmail to allow you to keep up with the patches.

• Be sure that /etc/utmp is mode 644. This may break some X11R5 (non-Sun) programs, however.

• Turn off all unnecessary RPC services (see below). If you must run tftpd, run it with the option: -s /tftpboot to limit the files it can transfer.

• Be sure all accounts have passwords or are disabled (with "NP" in the password field of the /etc/shadow file and /bin/false as the login shell).

• Only the root account should have user-id 0.

• NFS exports should be limited to specific hosts (see warnings below), and exports should be read-only where possible. Also, mount with the "nosuid" option to disable set-uid programs run from NFS-mounted partitions.

• Enable some console security by requiring an EEPROM-held password for any non-standard boot request. Use the command # eeprom secure=command to allow only "b" and "c" EEPROM commands without a password.

• Prevent IP-spoofing to help assure that hostnames and IP addresses match. For this you generally need a firewall, or a smart router.

• Never send passwords in clear text across unprotected networks (such as from a conference to your facility's server). Use S/Key or smart cards. If you do need to send a clear-text password, be sure to change it (when back at the ranch) as soon as possible.

• Perform periodic security checks on exposed, important machines. See November's column for a discussion of security monitoring tools.

If you combine this information with the patches and exposures we've discussed in this and previous columns, your systems will be in a good security state. Combining two secure systems with a firewall will provide you with as safe an environment as possible without overly inconveniencing the users (and causing them to seek workarounds to your security policies).

Bug of the Month Club

bind. Intruders are actively using a hole in bind to inject bogus DNS information. This bug allows the intruder to make DNS return inaccurate information. Consider the security implications of not being able to trust DNS. Do you allow rlogin or rtelnet at your site. Most sites do, and most sites place host names in the /.rhosts or /etc/hosts.equiv files to declare systems as trusted. Even worse, by default, Solaris (and most other flavors of Unix), allow your users to have their own ~/.rhosts files declaring remote hosts as trustable. Consider that NFS and rdist also use hostnames and IP addresses to authenticate clients...

Any trust that's based on the hostname of a system is also based on its IP address. If the translation between these two is incorrect (or sabotaged), you could end up trusting a host other than the one you expect.

The first step to correcting this situation is to upgrade to bind 4.9.3. Sun has not yet released this new version of bind as a security patch. If you can't afford to wait, download the latest version of bind from the public domain at ftp://ftp.vix.com/pub/bind/release/4.9.3/bind-4.9.3-REL.tar.gz. It, however, also requires a patch, find it at ftp://ftp.vix.com/pub/bind/release/4.9.3/Patch1.

Even the latest bind version does not fix all of the security issues of trusting DNS for authentication. My best advice is to be sure you don't allow DNS to do important translations for you. Rather, change the /etc/nsswitch.conf file on Solaris to use the local /etc/hosts file, NIS+, or even NIS before DNS. For more information on the DNS bug and solutions, check out the CERT advisory.

NSKIT. While we're stomping bugs, if you use the NSKIT you'll be interested in Sun patch 103053-01. NSKIT is the NIS server software ported to Solaris. When Solaris was released, NIS+ client and server code was included, but only NIS client code was included. If you used the NIS server, however, you had to continue running SunOS 4.x. Eventually, Sun's OPCOM group started selling a port of the NIS server, but it had some bugs. Finally, Sun has released NSKIT, the server NIS code, ported to Solaris. It's available on the newly-available migration initiative CDROM. It's free -- get one. This code is unsupported, but seems to work fairly well. Be sure to follow the installation directions!

Denial of service. For those who enjoy a good denial-of-service attack now and again (and who doesn't?), consider the results of establishing a connection between a machine's chargen and echo UDP ports. An infinite stream of bytes, signifying nothing. Entertaining, unless it happens to your server, in which case it's using up all your network and system bandwidth. Best solution: disable the services unless you really need them and use a firewall to disallow chargen and echo connections.

To disable echo and chargen, edit your system /etc/inetd.conf and comment out the appropriate lines. Next, send an HUP signal (# kill -HUP process-id) to the process-id of inetd. While you're there, consider disabling other unnecessary services, including uucp, tftpd, rquotad, rusersd, sprayd, fingerd, systat, netstat, and rexd. Especially rexd, because there is no known client that uses it and it does minimal authentication. For more information, see the CERT advisory.

sendmail Bug 1132A-3/2. Guess what? Another sendmail bug. This one involves all versions of sendmailyounger than 8.6.10. It allows local and remote users to execute privileged commands. The solution, as usual, is to upgrade to the newest version (currently 8.7.3). For more information, see the CIAC bulletin G-09.

The Bookstore

For interesting reading about the various network security scanners, what they do, and how they compare, check out the on-line review from the February 4th issue of PC Week.

For more information about packet filtering, especially as it relates to the above denial-of-service attacks, check out the CERT technical tip on the subject.

Corrections

We received a note from Frederick Avolio, from Trusted Information Systems (TIS), concerning our coverage of TIS in January's column. He makes three important points to consider if you're using the TIS toolkit:

• One cannot purchase support for the TIS Internet Firewall Toolkit (FWTK) from TIS or anyone. It is supported -- on a "best effort" basis -- via electronic mail to fwtk-support@tis.com.

• The firewalls mailing list is not really the best place for FWTK support, use the address above. There is also a users list -- fwtk-users@tis.com.

• People should be aware that the FWTK is not a complete firewall, in that they should also employ kernel modifications (such as TIS does with its Gauntlet Internet Firewall) or a screening router. The proxies alone will not protect against IP Spoofing, source routed attacks, and other assaults. Of course, if they are not experts they are much better off with a commercial firewall -- anyone's commercial firewall -- rather than thinking that all they need to know is how to type make at the Unix prompt.

Thanks for the info, Frederick.

Resources

• Sun's security cookbook
  http://sunsolve1.sun.com/sunsolve/security-news.html
• Sun patch list
  http://sunsolve.Sun.COM:80/pub-cgi/patchpage.pl
• latest version of bind
  ftp://ftp.vix.com/pub/bind/release/4.9.3/bind-4.9.3-REL.tar.gz bind patch ftp://ftp.vix.com/pub/bind/release/4.9.3/Patch1
• DNS CERT advisory
  ftp://info.cert.org/pub/cert_advisories/CA-96.02.README
• Sun's migration initiative
  http://www.sun.com/smcc/solaris-migration/index-new.html inetd CERT advisory ftp://info.cert.org/pub/cert_advisories/CA-96.01.README sendmail CIAC bulletin G-09 http://ciac.llnl.gov/ciac/bulletins/g-09b.shtml
• security scanner review
  http://www.zdnet.com/~pcweek/netweek/0205/tdaem.html
• CERT technical tip on packet filtering
  ftp://info.cert.org/pub/tech_tips/packet_filtering

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-03-1996/swol-03-security.html
Last modified: