>>Could somebody with better knowledge of Linux kernel enlighten me what >>will happen if attacker tries to install an adore-based kit (or other LKM >>kit) on a box already trojaned with LKM? I suppose new adore will take >>control from previous adore since it will remap kernel calls elsewhere, >>right? Or am I gravely confused here? ;-)
Adore acts in a non-destructive manner by wrapping the functions that it replaced. It is possible to layer adore modules -- however, depending on the configuration of the 2nd adore module, the functions of the first adore module may not be reachable (they would be intercepted by the outermost (or last loaded)) module. >> Any way to make sure my adore stays put? I looked at what StJude module >> is doing and it looks promising, but maybe something else can help? StJude, alone, does not protect the kernel from LKM rootkits. StMichael[1], which was integrated into StJude at version 0.20, does do checks for attacks/changes on/of the kernel's integrity after its load. If you are simply trying to keep adore out of the kernel, use StMichael with cloaking, and checksumming support. If you are using adore as a 'backdoor' into a honeypot, you can use StMichael too -- first load your adore, then StMichael[1]. Any subsequent kernel module rootkit loads will be detected and, in many circumstances, disabled. Silent mode would be appropriate here. [1] http://sourceforge.net/project/showfiles.php?group_id=13777&release_id=82067 [2] If you use StMichael 0.10, one modification is necessary -- you have to comment out the Bounds checking in StMichael_lkm.c, in order to bypass the on-load bounds checking of entries within the system call table. The bounds checking will check to ensure that the code for the system calls referenced in sys_call_table[] is within the text portion of the kernel. Adore's wrapped system calls would show up as being outside of the kernel text, since its a module, and cause StMichael to generate an error message and abort its load. Thanks, --Tim Tim Lawless, CISSP EDS Global Information Assurance Services * [EMAIL PROTECTED] The Views and Opinions Expressed within this document do not necessarily represent the views and opinions held by EDS GIAS, or EDS.
