Why Do I Have to Tighten Security on My System? (Why Can't I Just Patch?) - Page 2
The Lifecycle of the Modern Security Vulnerability
I. Bug Discovery
If we think about the security vulnerabilities that crackers exploit, whether locally or remotely, we realize that they're caused by one thing: a "bug" in either the design or the implementation of a system program. The lifecycle of this vulnerability starts when someone discovers this bug, through whatever method. They may be reading code or reverse-engineering the program, but they might as well be reading Internet RFCs describing a given protocol. In any case, the problem becomes a real possibility at the moment someone discovers this bug. It becomes a little worse if and when this person shares that knowledge with another.
II. Vulnerability Discovery
Now at some point, possibly seconds later, someone realizes that this "bug" actually leaves a security hole in the program. If this program has privilege, the vulnerability may be exploitable to gain that privilege. Again, the discoverer doesn't necessarily share this knowledge with anyone!
III. Exploit Coding
- Run arbitrary commands.
- Dump a section of memory containing passwords or other privileged information to a file.
- Write well-crafted data to the end of a specific file.
At this point, the vulnerability has become our problem. The exploit writer now has the capability to break into our machine - and we usually don't even know about the vulnerability. This is not good.
IV. Exploit Sharing
The exploit coder may share his exploit at this point. He can distribute it privately, among friends and acquaintances. Our problem just got worse, as there are now more people that can break into our machine and we may still not even know about the vulnerability.
V. Public Release!
Finally, one of the exploit owners may choose to release the exploit publicly, on BugTraq or other security mailing lists and possibly on security web sites. Our problem just got worse, in that now every script kiddie has access to a working exploit. Remember, there are tons of them and they're scanning the net indiscriminately, so we could be a target. But, our situation can finally be improved, in that someone might fix the vulnerability now! Remember, there's no guarantee that the vulnerability/exploit will ever reach this stage! Many exploits are circulated quite privately among cracker groups and thus don't become well-known for some time, if ever.
VI. Source Code Patch
Once the vulnerability is well-known, someone can code a patch. Often, the patch will be released on BugTraq and/or the vendor web site. This can happen very quickly in the Open Source community, but still often takes 1 hour to 4 days. Further, these source-code level patches are applied only by some sysadmins, who have the time and expertise to patch in this manner. Most admins wait for a vendor- supplied patch or update package.
Finally, realize that even for this first group, there has already been a sizable window of opportunity, in which their system could have been cracked. To see this, consider all the time between step III and steps IV, V and VI! In all this time, some number of crackers has had a working method of cracking our machine, usually before we've even heard about it!
VII. Vendor Patch
Now some number of days, weeks or months later, the vendor will release a patch. At this point our troubles, with this particular vulnerability, are usually over! Remember, though, there has been a sizable window of opportunity between initial coding of the exploit and the vendor patch. In these days, weeks or months, your machine has been rather vulnerable. Given the indiscriminate nature of the script kiddie, there's a very real chance that you could get hit!
Let's recapitulate the dangers here: first, many exploits are privately used, but not publicly announced for some time. Second, there's a delay between availability of exploit code and a source code patch. Third, vendors take quite a while to release that patch/update, leaving a large window of vulnerability in which you can be attacked. Fourth, there are a boatload of script kiddies out there, which means that while the exploit is publicly available, there's a number of people firing it indiscriminately against many random machines on the Internet. The only real way that we can stop the script kiddie is to actually take some proactive action.
Really Stopping the Kiddie!
Now that you realize that you've got to do something proactive to stop the script kiddie, let's consider what you can do. First, if you're on a Linux system, run Bastille Linux (shameless plug!). Bastille can harden a system for you very effectively with a minimum of hassle - it'll also teach you a fair deal in the process! You can also harden a system by hand, though it's likely to be less comprehensive than a Bastille run, unless you're using a very well- written checklist. If you do this all by hand, keep in mind these minimum important steps:
- Firewall the box - if possible, do this both on the box and on your border router to the Internet.
- Patch, patch, patch and patch some more. Automate this process, if possible, to warn you of new patches as soon as they're released. Please remember that the window of vulnerability is large enough without a sysadmin waiting two-four weeks to apply patches...
- Perform a Set-UID root audit of the system, to clear up as many (local) paths to root as possible. I show how to do this and perform one for Red Hat 6.x in my previous SecurityPortal.com art icle.
- Deactivate all unnecessary network services/daemons, minimizing the possibility of remote exploits!
- Tighten the configurations of all remaining network services/daemons to better constrain remote exploits.
- Harden the core O/S itself, through PAM settings, boot security settings and so on...
- Educate the sysadmin and end users!
As I said, Bastille does this stuff very well. Here's a real-world example of how hardening a box can be so much more effective than only patching: Red Hat 6.0 shipped with a BIND named daemon that was vulnerable to a remote root exploit. This vulnerability was unknown at the time, so no patch existed for a little while. If you had run Bastille, it had minimized the risk from any BIND exploit, known or unknown, by setting BIND to run as a non-root user in a "chroot" prison. When the exploit came out, people who hadn't hardened BIND were vulnerable to a remote root grab. Thousands of machines, at least, were rooted before patches were released and applied. If you had hardened ahead of time, by running Bastille or otherwise, the root grab failed. This example is just one of several - there were a few ways to root a Red Hat 6.0 box, all of which could be minimized by judicious hardening.
1 Actually, there are also hybrid exploits, where he gets an unprivileged shell on the system from some network daemon, without ever logging in but these are a hybrid type. Our script kiddie generally doesn't use this stuff, though he may if he's bright or has a good text file instructing him.
Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille- linux.org). He is the author of several articles on Unix/Linux security, along with the upcoming book Securing Linux the Bastille Way, to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes. 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.
The Focal Point for Security on the Net (tm)