Re: How real root kits run. (was: Re: Root Kit Protection)
On Thu, Feb 17, 2000 at 01:02:55AM -0500, Chad Miller wrote:
>
> My thoughts on the matter, for what they're worth... ("grain of salt",
> etc., etc.)
>
> If I were going to write a root-kit, I'd spend half an hour writing a
> kernel module that would give up the real file on an open() or fopen(),
> and run _my_ special program on execution.
>
> It would, of course, hide my files in space that I claim is free, and
> name itself to the kernel as something innocent-looking, like 'mtrr' or
> 'apm'.
quite right, however on a very high security system kernel modules
should be disabled, and all drivers etc needed should be compiled into
the kernel.
of course a step further one could replace the kernel with one that
includes those modifications and cause the machine to be rebooted and
they would hide the fact that the kernel was replaced.... but the
reboot would hopefully raise a huge red flag and cause further
auditing... (immutability bits and kernel secure levels might help in
this case too.)
> It's true this proposed program (and tripwire) would show corrupted,
> non-hidden root-kits, but there are plenty it wouldn't show. I think
> this might give a false sense of security to those who should have a
> healthy bit of paranoia -- especially those that think they need this
> program. That's the only downside to developing this program, IMO.
the `false sense of security' argument can go to far IMO, while I
agree this solution does not provide complete protection nor compete
security (there is no such thing) it does take care of many security
problems, I would guess that most script kiddy root kits do not go so
far as to modify the kernel and whatnot.. (i could be wrong)
I would counter this point by saying that all security measures could
be considered a false sense of security, permissions are completely
symbolic if one has a suid root shell stowed away somewhere, and
putting a login prompt on tty1-6 is just a false sense of security as
well, since there is rarly any security with physical access.... etc
etc
not a flame just a point that to some degree ALL security measures can
be considered `false sense of security' it does not mean they should
not exist or be implemented in many cases. rather i believe it means
there should be a further effort towards education on security and
that no lock can be made that cannot be picked so to speak...
> The real solution is a redesign of hardware that we usually use, but
> that's offtopic here.
>
> Ken Thompson's Turing Award speech gives some hints as to what's
> possible: URL: http://www.acm.org/classics/sep95/
>
> - chad
>
>
>
> ( Is your system running your kernel? Why do you think so? Because
> you asked the kernel the uname and the uptime? Because you asked it
> to open a file for you, so you could checksum it?
>
> /proc/mind </dev/paranoia
>
> )
--
Ethan Benson
Reply to: