Vulnerability Development mailing list archives

Re: Positive uses for rootkits


From: Gregor Binder <gbinder () sysfive com>
Date: Fri, 23 Mar 2001 10:54:37 +0100

Daniel McCranie on Wed, Mar 21, 2001 at 12:58:31PM -0600:

Daniel,

I have just enough UNIX knowledge to be dangerous to myself so be
gentle :)

.. obviously good enough to come up with an interesting question :)

1. Are most rootkits simply shell scripts or real programs?

rootkits are usually a collection of "real" (binary) programs that
have been modified from the original source, sometimes include or solely
consist of a kernel module. There will usually be a shell script used to
install those programs, be it pasted into the shell by the attacker, or
included with the tarball. It could also be a self extracting shar.

2. Would there be anyway to stop programs from overwriting those
files with programming calls?  (Maybe making them read-only and
modifying chmod...)

You'd actually have to modify the chmod set of system calls, that means
it would have to be done in the kernel. The reason for this is that
changing mode/ownership, deleting, moving et al do not depend on the
commands chmod/chown, rm, mv being used, but can also implemented by
using the respective (set of) calls from an arbitrary program.

So you would have to make the system calls aware of what needs to be
protected. This would stop a lot of script kiddie attacks, but would
not stop an attacker who is able to modify the calls in memory. BTW,
an elaborate rootkit would maybe not even change a file on disk, but
just modify your system behaviour by modifying calls in memory.

3,4,5: I know that this probably wouldn't be good in a standard
distro but what about a hardening kit?  Has this been tried before?
Is there something blatantly wrong?

Your idea, and things that need to be implemented along with it to make
it work properly is present in some trusted UNIX systems. If you are
interested in this kind of functionality, look at Trusted Solaris, HP
Virtual Vault, the work available at trustedbsd.com, IRIX CMW, and maybe
read about the concepts of trusted operating systems at
  http://csrc.nist.gov/secpubs/rainbow/std001.txt

As for hardening kits, argus systems provides a solution that can be
evaluated for free on Solaris and Linux at
  http://www.argusrevolution.com/

Though calling it a hardening kit would be an extreme understatement :)

Free solutions for Linux are available (I think), but I don't have much
clue about those, maybe somebody else does?

You will notice, when you look at any of the above, that none of these
have a single configuration file where you state which files you want to
protect, but this is implemented through relatively complex mechanisms
of defining access control and limiting what a user (maybe even root if
it still exists) can do on a system. So you are right in thinking it
might not be the right thing for everybody, especially since all of the
commercial OSs/tools come at a relatively high price and require a very
high level of understanding from the sysadmins.

For most applications, establishing a good OS security (see the tools
sections on securityfocus.com and other relevant sites for hardening
scripts, advice, information on ACLs), properly setting up users and
groups and running services as different unpriviledged users will
usually suffice, unless your systems contain classified information or
are used for monetary transactions.

You might want to look at OpenBSD as well, which does not have trusted
features, but comes relatively secure out-of-the-box, and provides
some kernel methods to protect your system to a very high degree,
including the functionality you asked for (chflags), which might be in
other *BSDs as well.

Regards,

--
Gregor Binder       <gregor.binder () sysfive com>      http://sysfive.com/
sysfive.com GmbH               UNIX. Networking. Security. Applications.
PGP id: 0x20C6DA55 fp: 18AB 2DD0 F8FA D710 1EDC A97A B128 01C0 20C6 DA55


Current thread: