[25162] in bugtraq
=?utf-8?B?562U5aSNOiBBbiBhbHRlcm5hdGl2ZSBtZXRob2QgdG8gY2hlY2sgTEtNIGJhYw==?=
daemon@ATHENA.MIT.EDU (Wang Jian)
Thu Apr 18 23:01:30 2002
From: "Wang Jian" <lark@marsec.net>
To: "'Florian Weimer'" <Weimer@CERT.Uni-Stuttgart.DE>,
"Paul Starzetz" <paul@starzetz.de>
Cc: <bugtraq@securityfocus.com>
Date: Thu, 18 Apr 2002 10:59:46 +0800
Message-ID: <000101c1e685$19cabb40$8100a8c0@marsec.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
In-Reply-To: <87g01ux9qg.fsf@CERT.Uni-Stuttgart.DE>
Content-Transfer-Encoding: 8bit
> -----原始邮件-----
> 发件人: Florian Weimer [mailto:Weimer@CERT.Uni-Stuttgart.DE]
> 发送时间: 2002年4月18日 06:05
> 收件人: Paul Starzetz
> 抄送: Wang Jian íõ½￡ [±±¾©]; bugtraq@securityfocus.com
> 主题: Re: An alternative method to check LKM backdoor/rootkit
>
>
> Paul Starzetz <paul@starzetz.de> writes:
>
> > Be sure that this will be fixed in the next 'generation' of LRKM's.
> > Patching the device methods for disk special nodes is not a
> big deal -
> > why not to incorporate even your code into one of the nice
> LRKM's? You
> > probably found a weaknes of 'current' LRKM's but in general
> it is a bad
> > idea to check your machine while running a compromised kernel.
>
> I agree. You can never be sure which kernel you are running. An
> attacker could have placed a modified kernel on a swap device (which
> excludes this very area from being used as swap space), and tweaked
> the boot loader to load the modified kernel.
If the file integrit check reveals that the boot loader is tweaked, the LKM
loses the game in the first place, other tricks are just futile. Rewrite boot sector
to a correct one will be enough for recovery.
If it hide the hacked boot loader, then my code can reveal it unless it also
intercept the raw disk io layer.
This specific example is very simple to check and overcome. If you want to:
1. swapoff this device
2. dump it to a file
3. format it again
4. swapon it
The LKMs can only continue the game by intercepting raw disk io.
> Using this approach, the modified kernel image can be made completely
> invisible easily, and it still survives reboot. Such a modification
> is very hard to spot even during an offline analysis, and the
> checklists I've seen so far do not address this problem at all.
>
> --
> Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
> University of Stuttgart
http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
