[<prev] [next>] [day] [month] [year] [list]
Date: Sat, 2 May 2020 11:41:17 +0300
From: Nikolay Zorin <zorin@...mel.ru>
To: lkrg-users@...ts.openwall.com
Subject: Re: fake alert (?)
hello!
AppArmor - added, but not configured.
and also: I tried the last commit of the SRC, where didn’t work on
CentOS 6.10, on VmWare 6.7 and CentOS 7.4 - work, no warn\error
I update src from git (commit
'c8e18884a6bb18b4ddcccfd9c2776e4c3472392f', from 'Date: Fri May 1
21:59:28 2020 -0400') and.. and on KVM CentOS 6.10 (version KVM is
0.12.1.2-2.491) kernel with this module work, but with warn (approx one
time in or 50 sec or 5 min, no visible dependets):
May 2 04:21:29 auto kernel: [ 277.179232] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.327245] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_JMP]!
May 2 04:25:45 auto kernel: [ 533.330909] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.334139] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_JMP]!
May 2 04:25:45 auto kernel: [ 533.338107] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.340707] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_JMP]!
May 2 04:25:45 auto kernel: [ 533.344701] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.347779] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_JMP]!
May 2 04:25:45 auto kernel: [ 533.351774] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.354617] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_JMP]!
May 2 04:25:45 auto kernel: [ 533.358612] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.388238] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_NOP]!
May 2 04:25:45 auto kernel: [ 533.392220] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.395204] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_NOP]!
May 2 04:25:45 auto kernel: [ 533.400189] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.406643] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_NOP]!
May 2 04:25:45 auto kernel: [ 533.410635] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.414008] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_NOP]!
May 2 04:25:45 auto kernel: [ 533.417982] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
May 2 04:25:45 auto kernel: [ 533.421320] [p_lkrg] [JUMP_LABEL] New
modification: type[JUMP_LABEL_NOP]!
May 2 04:25:45 auto kernel: [ 533.425314] [p_lkrg] [JUMP_LABEL]
Updating kernel core .text section hash!
I tried VmWare 6.7, CentOS 7.4 (KVM version is 1.5.3-167) - same behavior
P.S. default 'log_level' is 3
02.05.2020 04:57, Adam Zabrocki пишет:
> 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
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.
