In my time as a Security Administrator for a Solaris shop, I had to give the occasional briefing to my boss: We’re vulnerable. A new security hole has just been discovered and every major Unix/Linux is vulnerable, from Solaris to Irix to Red Hat Linux. After briefing my boss on our risk and my plans to do something about such, he asks me the same question: "Can you find an exploit?" Rather often, I’ve had to answer, "nope."
Actually, my answer is usually something like: "I’ve found an exploit against the Linux version, but no one’s releasing it widely for Solaris yet." My boss is both partially relieved and partially bothered. Why?
My boss asks me to find an exploit for two reasons:
He wants to confirm that we actually are vulnerable.
When I’ve fixed it, he wants to confirm that we are, in fact, no longer vulnerable.
The second part of this is fairly important to us. We think we’ve corrected our problem, but we can’t really be sure until we actually test the "gun," the cracker exploit. It’s like buying a new bulletproof vest without ever seeing it tested. You’re risking pretty vital assets on the word of the vendor! So, my boss is upset that we can’t test our vulnerability or the fix.
He’s also relieved, as I have been on many occasions, because once again, either all the crackers are coding exploits for Linux/FreeBSD or the crackers are only distributing exploit code against Linux/FreeBSD. I suspect this is mostly due to the fact that most people, and thus many uber-haxors, only have easy access to a Linux or FreeBSD box. Solaris, Irix, AIX and HP-UX boxes are much harder to come by, especially for our exploit coder working from home.
I may be wrong here. It’s possible that exploits are quickly coded for every Unix/Linux out there, but that the only ones widely distributed are for Linux/FreeBSD 1. Well, then, the difference is chiefly academic! In reality, I don’t have a large number of script kiddies running exploits against my Solaris boxes, while many of them are constantly hammering at the Linux boxes.
In any case, this is a serious strike against Linux’s security as a server operating system. Linux seems to have become the "number 1 target." The bulk of the new exploit code is coming out for Linux, even for vulnerabilities present in all Unices.
Is Jay A Linux Turncoat? A Solaris Lover?
"Wait," you say! "Didn’t you say you were a Linux convert? Heck, aren’t you leading development of a project specifically made to secure Linux?!"
Well, there is another side to this. While the bulk of the cracker research is going toward Linux/FreeBSD, there’s a whole heck of a lot of research going into the other side of the battle, Linux Security. The work going on there is pretty impressive. Let’s take a look.
There is serious ongoing, successful, development in Linux kernel enhancements. This includes kernel patches that allow a sysadmin to control which kernel-level "system calls" are allowed to each process, and under which conditions. Medusa DS9 is one chief example of this, as is LIDS, the Linux Intrusion Detection System. Each of these allows you to place extremely granular (specific) restrictions on any given program or user. For example, we could restrict the BIND DNS server to read access on its particular data and write access only to a log file. This scheme would have crippled the recent BIND remote root vulnerability – the attacker would have had virtually no rights to modify the filesystem. A colleague of mine used WireX‘s SubDomain tool to do the same thing. SubDomain limits a process’s file access to a small subset of files, creating a stronger process "jail" than the traditional "chroot" jail most of us use. WireX also makes an altered compiler, using their Stackguard technology to block many of the popular "stack-smashing" exploits.
There are other kernel-level tools. Solar Designer’s Openwall kernel patch enforces several other security measures, doing things like enforcing stricter permissions on the /proc filesystem and implementing a non-executable stack. This is only the research in kernel enhancements – there is a great deal of work going on in this realm, as I hope to show.
There are a number of others. Bastille Linux is one such project. It enhances Linux security in a different way, by tightening settings on a Linux distribution using modules to do the following:
Configure and implement a personal or LAN firewall.
Tighten user account security.
Run a Set-UID root audit, restricting an attacker’s possible local pathways to root access.
Configure access restrictions on Apache, deactivating CGI or Server Side Includes or restricting the server to specific interfaces.
Tighten the boot process, from password-protecting LILO to disallowing LILO prompt input at all.
Implement user process limits and other security features through PAM.
Chroot and restrict the DNS server to a non-root user.
Restrict and/or deactivate FTP and other "broken" protocols, like rsh, rlogin, rcp.
Deactivate miscellaneous daemons, from atd to gpm.
Enhance the host’s logging mechanisms, adding files and terminals.
Restrict attacker’s access to, and within, sendmail.
Further, Bastille educates the installing system administrator. This provides an immense aid to system security, because a security-educated and security-conscious admin is one the most effective components of a secured system. Ahhh, enough plugging my own project. There are a number of projects to enhance Linux security, many of which have no analogue in other operating systems.
OK, so Linux has an advantage over other operating systems: Tons of research! Let’s look at another: Faster patches.
Linux Has Speed of Development
Remember the "ping of death" incident a few years back? It affected basically every vendor, but they all took a varying amount of time to respond. The Linux people, if I remember correctly, took less than 24 hours to issue a fix.
We’ve seen a great deal of evidence for Linux’s speed in releasing patches, compared with the other vendors. A SecurityPortal study showed that Red Hat was much, much faster than other major vendors, including Sun, in responding to security vulnerabilities. This speed comes from the open source nature of the operating system, which permits anyone to propose fixes to bugs, along with the sheer number of programmers working on it. While Red Hat’s average response time was 11 days, Sun took a whopping 3 months, on average! This time difference is incredible!
Now, in my experience, a patch from the original open source programmer is generally released within 2-7 days on Linux. A competent system administrator can patch vital machines with this in the meantime, so Linux enjoys even shorter vulnerability times. The point here is this: An attentive system administrator should be able to keep Linux fairly fault-free for long stretches of time. He won’t find the same pattern with Solaris, where he’ll have long stretches where he’s vulnerable. This speed on development, and on patching, is one of Linux’s major security advantages. Combined with the sheer number of security enhancements developers are writing/have written, it has the potential to be one of the strongest general purpose operating systems around!
Conclusion – Do I Run Linux?
OK, so I’m going to keep working in Linux. I’m going to keep recommending it to my fellow security-conscious IT types. This is despite the downsides: Linux is being pounded on by a number of crackers. Those with capability to create exploits have more access to Linux boxes, because of the popular nature of the Intel x86 hardware. If you’re not deploying Linux security solutions, or actively trying to patch your servers, maybe it isn’t the operating system for you! Then again, maybe you shouldn’t be administering boxes. On the other hand, you’re reading SecurityPortal 2. Chances are good that you care and put time into your site security. And if you want an operating system with the capability to be more secure than any Unix or Windows platform currently out, Linux should be your bet. It takes time and effort, but you can make it extremely secure.
1 Kurt Seifried insists that "there is a lot of exploit code for the commercial Unices, but the kind of hacker that goes out and buys a sparc so they can run Solaris and "properly" code/test exploits is not the kind that is likely to widely share their exploit code."
About the Author
Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille-linux.org). He is the author of a number of articles on Unix/Linux security, along with the upcoming book Securing Linux the Bastille Way, to be published by Addison Wesley. At his previous day job, Jay was a security admin working on Solaris and Linux boxes. At his current job, Jay is working on a well-known Linux distribution. You can learn more about his articles, talks and favorite security links via http://www.bastille-linux.org/jay.
SecurityPortal is the world’s foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
Th e Focal Point for Security on the Net ™