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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
