Report from SANS '98
Why Wietse Venema says sendmail can never be made secure and more
Didn't have time to hit the hottest network security conference of the season? Have no fear, Peter Galvin was there. This month he reports on the SANS conference held in Monterey, CA recently. Find out what went on at the best sessions and get Peter's take on the all-important trinket-disbursement situation.
Also this month: Reader tips on setting up a padded cell, bugs, break-ins, and the Stalker's Home Page. (2,600 words)
s long-time readers already know, I'm a fan of both the SANS (System Administration Networking and Security) conference and its sister show, the Network Security conference. I had high expectations going into SANS, but was overwhelmed by the quantity of quality, interesting talks available. I counted no fewer than 21 talks I wanted to attend, and most of the ones I did manage to make were terrific.
There was too much going on at the conference to report on everything (and Monterey, CA, where the conference was held, holds its own interesting diversions, including a well-named local microbrew called Peter B's), so I'll confine myself to reporting on the interesting security-related talks I attended.
If you missed the conference, the good news is that almost all of the talks are on a proceedings CD. You can get this from the SANS Web site (see Resources below). Printed proceedings, course materials, and other goodies are also available. However, you may find these offerings to be a poor substitute for attending a conference. Most of the entries are just copies of the slides that were presented at the talk (I'm as guilty of this as the other speakers). These handouts can serve as a good reminder of what was said, or a good place to scribble notes, but nothing beats attending the talk yourself. Hopefully, this column will serve as the next best thing.
Turning off sendmail forever
One of the highlights was the talk by Wietse Venema about the work he is doing as a visiting fellow at IBM's T. J Watson Research Center. Wietse is well-known as the author of one of the most useful, and well-used free security tools: tcp-wrappers. He also co-authored the network analysis tool, Satan. Wietse says he's decided that sendmail can never be made secure. Rather, he thinks it should be replaced by a program that can be secure. The fundamental problem with sendmail is that it must be setuid-root. Wietse has designed a mail delivery agent that doesn't have that weakness. The mailer, which he plans to use as an example in a forthcoming book with Dan Farmer, has several goals, including:
So far, so good. Of course there are challenges in implementing such a package, including a lot of broken (PC) software that doesn't correctly speak network protocols, concurrent mail database access, mail address parsing and routing, and queue management. Wietse also wants to include spam/relay control. The basic architecture dictates that the mail system server run as a user mail system. This component receives mail from remote and local senders and stores it in a mail queue. Then a setuid-root component delivers mail from the mail queue to local mailboxes or remote systems, as appropriate. In this way, there is no user interaction with the setuid-root component. This architecture also solves several other long-standing security problems with sendmail, such as /tmp race conditions, remote data in shell variables, and fixed-length string buffers.
In terms of compatibility, the vmailer package works with /etc/aliases, NIS aliases, and NetInfo aliases, /var/spool/mail/user, forward files, and file and pipe delivery. There is no sendmail.cf however. The performance is good, but Wietse wants more. He's done some performance testing and the bottleneck is -- and you could have guessed this -- file creation performance. Unix file creation is done synchronously, so every incoming mail message causes a physical disk wait while its inode is allocated and updated. Current performance is 5.3 messages per second being received and 75 deliveries per second. Wietse is working on solving this problem as well as adding new features, including more configuration options and a scripting language. Currently, the code is in public beta release, and it has been used in place of sendmail at several locales. It's available for most common versions of Unix. No, it won't run on Windows.
I attended several interesting short but in-depth courses, including:
I also attended several interesting talks about security and systems management:
The SANS organization distributed a couple of useful handouts. One was its annual salary survey. It's not only interesting for its numbers, and their subsequent use both by managers and managees (usually to different ends), but also for the advice it contains. There are stories from people about how they secured themselves larger-than-average raises. There are also tips for managers on how to keep your best technical people.
Another useful handout was the Windows NT security step-by-step guide, labeled as a survival guide for Windows NT security. Written by more than 100 contributors, this 32-page guide has a unique format. Some of the steps are obvious: avoid using shared accounts, protect ports via a firewall, and restrict anonymous logon. Those suggestions bear repeating, however, as intruders continue to take advantage of these common weaknesses. But most of the steps in the guide are valuable -- even more valuable are the "actions" associated with each step. Specific changes, including registry keys and their values, are included with each. This guide should be useful for those dealing with NT security, from the novice to intermediate level.
Unfortunately, there were no standout trinkets at this year's vendor show. There were plenty of T-shirts to go around though. There were also a few "hostility" suites in which vendors tried to hold presentations or discussions while potential customers ate and drank. The welcoming party hosted by SANS and the conference hotel was quite a lot of fun, with model-car racing, pinball, video games, and other games of semi-skill. Quite a few brave souls made fools of themselves riding around a circle on motorized garbage cans (yeah, you had to be there). Generally, the conference was very smoothly run, with plenty to do and very few snafus along the way. If there was one problem, it was not having enough time to explore the areas surrounding Monterey. Maybe next time the talks won't be quite so compelling.
Sun has released security bulletin #170 about the rpc.nisd daemon. This RPC daemon is required on all NIS+ servers. Unfortunately, there's a buffer overflow possibility in all OS releases, which could lead to root access via the network. Patches for all recently OS releases are now available.
Sun also released bulletin #171, describing a potential denial-of-service attack in all recent releases of in.ftpd. Again, patches are available.
It's been an unprecedented couple of months on the break-in front. Most recently, three teenage computer hackers claim to have broken into computer systems at India's Bhabha Atomic Research Center (BARC) and say that they are targeting Pakistani computers in a protest against the two nations' recent nuclear weapons tests. Apparently the hackers gained access to six of eight servers in the barc.ernet.in domain, stole copies of e-mail between scientists, and modified the Web server contents. No one seems to know exactly how much sensitive or classified information these kids got their hands on.
Also in the news, was the Rt66 break-in. This ISP was taken down for nearly 36 hours after a root disk was erased on one of its systems. The ISP was a bystander when one of the sites it hosts, Carolyn Meinel's King of the Hill Web site, issued a challenge to "hack this site." Both the Web site and the ISP were attacked. They were subjected to an average of 1,000 hack attacks a day. Almost all were repulsed, but one managed to get root access on one of the ISP's servers and do the damage.
If this column whets your appetite for attending security conferences, you should make plans now to attend Network Security '98, in Orlando, FL, from October 24 to 31.
After that, the next major conference is LISA '98, to be held in Boston in December.
The topic of building padded cells for Web and mail servers elicited quite a lot of reader response. Many asked for help in building the padded cells. Most of these were resolved with judicious use of truss to determine why programs were failing in the padded cell. There were also several good comments and suggestions, not to mention differences of opinion.
Gilles Ciselet from IBM Belgium points out some common variations that may be required at sites with requirements differing from our project. He writes:
I was really happy to read your column regarding the Web server in the padded cell.
I've designed Web hosting systems and I'm happy to learn I'm not the only one out there using this. What inspired me from the beginning was the "virtual servers technology."
What I disagree with is the sendmail set up: Customers very much like to put a cgi script that sends mail (e.g., Formmail.pl). The approach I have taken is to remove the suid bit from sendmail, and I've granted enough permissions to the queue directory. Of course there's only one customer per cell. I believe the padded cell security is good as long as you don't have suid root programs in it, since root can escape a chroot.
One last thing: As customers need both FTP and telnet I needed to put quite a lot in /usr (shells, terminfo, etc.), so I made a new filesystem with all the code and mounted it as read-only over the /new/root/usr directory.
The basic principle is to allow only what is necessary. If sendmail is necessary, include it, but only with minimum privileges. Certainly adding complexity can result in security problems, but as Gilles points out, the end result is almost certain to be more secure than the non-chrooted alternative. The read-only idea is a good one. Certainly not fool-proof, as a mount can be re-mounted read-write, but at least it's another layer in the security onion.
The Stalker's Home Page reminds us that the Web is like a nuclear bomb -- it can be used for good or evil. The page has links to many sources of information, which can be used together to gather quite a lot of information about an individual. Some of the sources cost money, but you can also find many interesting things for free. On the page, you can look up all sorts of personal information: addresses, social security numbers, and other personal details. Is this a cautionary tale of our diminishing privacy? Or just someone spreading a lot of FUD? You decide.
The column about secure programming apparently struck a nerve. It seems that few companies are taking security into account when creating programs, which results in potential security problems. Next month, I'll present a secure-programming FAQ that includes a succinct list of dos, don'ts, whys, and why-nots. Hopefully, that will help the industry move forward and start producing code that's solid and secure -- not just more hacker bait.
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, and has been program chair for the past four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials worldwide 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 co-author of the best-selling Operating Systems Concepts textbook. Reach Peter at firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com