Re: HELP I've been cracked
On Monday, February 11, 2002, at 02:54 PM, Jeff Bonner wrote:
But if the machine is restarted, those changes either do not persist
(same kernel) or are quite obvious (modified kernel overwrites the old
one, etc). On the other hand, having a hostile module inserted
into the
kernel not only allows persistence, it is much harder to detect
with IDS
tools.
Huh? How is there any different. Assuming you reboot off clean
media to check for security issues (of course you do), loading a
module automatically will show as a change in some file on the
file system.
Loading a "module" via poking in kernel memory will show the same.
If you check by rebooting off the suspect media, then there
really isn't any reason for the trojaned kernel to show you
anything. Code to do this is readily available.
Linux has an abundance of malicious LKMs, ready for anyone to download
and implement, so I see this as a primary method to potentially exploit
my system. YMMV.
There are the same for systems without modules, unfortunately.
I've seen it published on the web. No URL; sorry. Maybe Google
can find it.
BTW, you can seal off /dev/kmem and /dev/mem. This of course
results in
X not working, but that's fine, this is a server.
True. Though there are many other ways. i/o ports come to mind.
Also, I wouldn't be surprised at all if root can trigger buffer
overflows (for example) in the kernel.
Root, God, what's the difference, as the saying goes.
I'm not saying this is the answer to every possible scenario.
There are
a number of other items to tick off the "security checklist", such as
read-only media. When added up, they make it a lot harder for the
casual skript kiddie to come along and wreak havoc -- and hopefully
less-than-determined blackhats -- but I don't for a minute think I'm
impenetrable.
Here, we agree completely.
Reply to: