[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20200502015721.GA5837@pi3.com.pl>
Date: Sat, 2 May 2020 03:57:21 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: fake alert (?)
Hi,
On Fri, May 01, 2020 at 11:31:26PM +0300, Nikolay Zorin wrote:
> Hello!
>
> I integred LKRG into kernel (not a external module (*.ko)) 0.7 (release) -
> work, but constantly (every 15 sec) writes alerts:
> May 1 05:50:33 auto kernel: [ 862.594157] [p_lkrg] ALERT !!! _RODATA
> MEMORY BLOCK HASH IS DIFFERENT - it is [0x8c6073d11381f2f1] and should be
> [0x117e94a7b467f213] !!!
> May 1 05:50:33 auto kernel: [ 862.594157] [p_lkrg] ALERT !!! SYSTEM HAS
> BEEN COMPROMISED - DETECTED DIFFERENT 1 CHECKSUMS !!!
>
Right. It looks like that someone / something modified RO data section after
LKRG has snapshoted the hash from it. You would need to identify which module
(or which part of the system) modifies RO-data. If LKRG starts running after
such modification happens, it will guard that modified data.
> I expanded output:
> May 1 12:40:21 auto kernel: [ 92.284458] [p_lkrg] ALERT !!! _RODATA
> MEMORY BLOCK HASH IS DIFFERENT - it is [0x3c5d2385a7efe483] and should be
> [0xe437fa03a2808bea] !!!
> May 1 12:40:21 auto kernel: [ 92.284458] module name (from 'list array')
> - snd_hda_codec_generic
> May 1 12:40:21 auto kernel: [ 92.284458] module name (from 'kobj
> array'-floppy)
> May 1 12:40:21 auto kernel: [ 77.180260] [p_lkrg] ALERT !!! SYSTEM HAS
> BEEN COMPROMISED - DETECTED DIFFERENT 1 CHECKSUMS !!!
>
>
> I unload 'floppy', but message not stop:May 1 12:52:26 auto kernel: [
> 817.276319] [p_lkrg] ALERT !!! _RODATA MEMORY BLOCK HASH IS DIFFERENT - it
> is [0x3c5d2385a7efe483] and should be [0xe437fa03a2808bea] !!!
> May 1 12:52:26 auto kernel: [ 817.276319] module name (from 'list array')
> - snd_hda_codec_generic
> May 1 12:52:26 auto kernel: [ 817.276319] module name (from 'kobj
> array'-virtio)
>
I don't think this has anything to do with modules. However, it might be
possible that some of the module do modify RO-data.
> If I integrated last version from 'git' (non experimental), then system not
> start and not output messages..
>
That's is more concerning. LKRG 0.7 is pretty old release. Latest LKRG from the
repo is the one which you should try. To be able to find out what's going on,
you can change the default LKRG log_level to be at least 4 (log_leve=4). This
should print more information. If you enabled debugging compilation there is
also log_level 5 and 6. I'm not recommending using it since it will kill the
kernel logging (too much information). However, If your kernel can't be booted
it might be worth to try to see what's going on.
> my system (virtual, KVM based CentOS 6.10):
> # uname -a
> Linux auto 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1.swm.3 (2020-04-27) x86_64
> GNU/Linux
>
> standard Debian + 'AppArmor' and remove IPv6 (himself rebuild)
>
> what to do next?
> what additional information to provide?
>
increase log_level for LKRG from repo.
For 0.7, find out who modifies RO-data section. You can try to 'run/load' LKRG
later in the boot phase, after such modification are applied. It can be
possible that some AppArmor rules do modife RO-data.
Thanks,
Adam
>
> Thanks
>
> --
> Nikolay
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
