Weblog entry #9 for oxtan
See all weblog entries made by oxtan.
#9
chkrootkit and false positives?
Posted by oxtan on Fri 26 Jan 2007 at 08:00
I recently upgraded a sarge box with a self-compiled kernel to the standard 2.6.8.* kernel of an updated sarge.
This morning I saw this in the daily report:
Checking `lkm'... You have 2 process hidden for ps command
Warning: Possible LKM Trojan installed
so I ran
# chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v -p 3
###
....
PID 20605: not in ps output
CWD 20605: /usr/sbin/mysqld
EXE 20605: /usr/sbin/mysqld
PID 20606(/proc/20606): not in readdir output
PID 20606: not in ps output
CWD 20606: /
EXE 20606: /sbin/apcupsd
....
You have 1 process hidden for readdir command
You have 2 process hidden for ps command
I came accross this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278
It looks like there was a problem before with procps, which should be solved by now. Still, I have the messages. I know chkrootkit is not foolproof, far from that, but I honestly do not think I am rooted. Any ideas?
This morning I saw this in the daily report:
Checking `lkm'... You have 2 process hidden for ps command
Warning: Possible LKM Trojan installed
so I ran
# chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v -p 3
###
....
PID 20605: not in ps output
CWD 20605: /usr/sbin/mysqld
EXE 20605: /usr/sbin/mysqld
PID 20606(/proc/20606): not in readdir output
PID 20606: not in ps output
CWD 20606: /
EXE 20606: /sbin/apcupsd
....
You have 1 process hidden for readdir command
You have 2 process hidden for ps command
I came accross this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278
It looks like there was a problem before with procps, which should be solved by now. Still, I have the messages. I know chkrootkit is not foolproof, far from that, but I honestly do not think I am rooted. Any ideas?
Comments on this Entry
I doubt it is a rootkit, but the only way to tell is shutdown, boot from clean media, and verify the integrity of everything.
Unless I had suspicions I'd probably be content if restarting mysql and apcupsd got rid of them, and restarted things appropriately. Although it is possible the shutdown scripts may barf if the ps output isn't accurate.
If it is the bugs, it probably is fixed by now, but it may not be in sarge. I've run much more recent kernels built from stock source with kernel-package on sarge, if you feel a fix is crucial.
I get a lot of transient false positives from chkrootkit, but they are usually just processes changing state when it runs. Chkrootkit likes to imply that dhcpd is promiscuous, sounds like slander to me ;)
Unless I had suspicions I'd probably be content if restarting mysql and apcupsd got rid of them, and restarted things appropriately. Although it is possible the shutdown scripts may barf if the ps output isn't accurate.
If it is the bugs, it probably is fixed by now, but it may not be in sarge. I've run much more recent kernels built from stock source with kernel-package on sarge, if you feel a fix is crucial.
I get a lot of transient false positives from chkrootkit, but they are usually just processes changing state when it runs. Chkrootkit likes to imply that dhcpd is promiscuous, sounds like slander to me ;)
[ Parent | Reply to this comment ]
I tried restarting the service apcupsd but I got an 'Ooops' from the kernel:
Jan 27 12:55:58 tux apcupsd[20605]: apcupsd exiting, signal 15
Jan 27 12:55:58 tux apcupsd[20605]: apcupsd shutdown succeeded
Jan 27 12:56:01 tux /USR/SBIN/CRON[9363]: (root) CMD (/sbin/adslscript)
Jan 27 12:56:09 tux kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000c45
Jan 27 12:56:09 tux kernel: printing eip:
Jan 27 12:56:09 tux kernel: d4ae55a2
Jan 27 12:56:09 tux kernel: *pde = 00000000
Jan 27 12:56:09 tux kernel: Oops: 0000 [#2]
Jan 27 12:56:09 tux kernel: PREEMPT
Jan 27 12:56:09 tux kernel: Modules linked in: ide_cd cdrom evdev pcspkr floppy snd_ens1371 snd_rawmidi snd_seq_device snd_pcm snd_page_alloc snd_timer snd_ac97_codec es1371 gameport ac97_codec aic79xx uhci_hcd
pci_hotplug intel_agp agpgart usbhid nfsd exportfs lockd sunrpc sch_htb sch_ingress cls_fw cls_u32 sch_sfq sch_cbq ppp_deflate zlib_deflate bsd_comp ppp_synctty ppp_generic slhc ipt_REDIRECT ipt_REJECT ipt_rec
ent ipt_length ipt_TOS iptable_mangle usbcore parport_pc lp autofs4 ipv6 genrtc snd_mixer_oss snd soundcore dm_mod capability commoncap 3c59x ipt_conntrack ipt_ULOG aic7xxx st tun loop ip_nat_irc ip_conntrack_i
rc ip_nat_ftp ip_conntrack_ftp parport ipt_mark ipt_state iptable_filter ipt_MARK ipt_MASQUERADE iptable_nat ip_conntrack ipt_LOG ip_tables af_packet ext3 jbd mbcache ide_generic piix ide_disk ide_core sd_mod a
ta_piix libata scsi_mod unix font vesafb cfbcopyarea cfbimgblt cfbfillrect
Jan 27 12:56:09 tux kernel: CPU: 0
Jan 27 12:56:09 tux kernel: EIP: 0060:[<d4ae55a2>] Not tainted
Jan 27 12:56:09 tux kernel: EFLAGS: 00010286 (2.6.8-3-686)
Jan 27 12:56:09 tux kernel: EIP is at hiddev_ioctl+0x32/0x920 [usbhid]
Jan 27 12:56:09 tux kernel: eax: cd44acc0 ebx: 00004802 ecx: ca536800 edx: fffffffb
Jan 27 12:56:09 tux kernel: esi: 00000000 edi: 00000001 ebp: 00000000 esp: c189fef0
Jan 27 12:56:09 tux kernel: ds: 007b es: 007b ss: 0068
Jan 27 12:56:09 tux kernel: Process apcupsd (pid: 9370, threadinfo=c189e000 task=d3f1ef30)
Jan 27 12:56:09 tux kernel: Stack: d37d39c0 00000000 c189e000 cc3e3e60 00000000 d4a41a00 c015e392 d339eb54
Jan 27 12:56:09 tux kernel: d37d39c0 00000103 c9d5e32c d37d39c0 d339eb54 d3fbbaa0 d3fbbaa0 c0153cfc
Jan 27 12:56:09 tux kernel: d37d3a08 d339ebec 71d4d9d3 00000102 0808b7f8 cea9e000 c189e000 c0153be8
Jan 27 12:56:09 tux kernel: Call Trace:
Jan 27 12:56:09 tux kernel: [<d4a41a00>] usb_open+0x0/0x1f0 [usbcore]
Jan 27 12:56:09 tux kernel: [<c015e392>] chrdev_open+0xf2/0x220
Jan 27 12:56:09 tux kernel: [<c0153cfc>] dentry_open+0x10c/0x240
Jan 27 12:56:09 tux kernel: [<c0153be8>] filp_open+0x68/0x70
Jan 27 12:56:09 tux kernel: [<c01681cc>] sys_ioctl+0x11c/0x280
Jan 27 12:56:09 tux kernel: [<c010603b>] syscall_call+0x7/0xb
Jan 27 12:56:09 tux kernel: Code: 8b b7 44 0c 00 00 85 c0 74 64 81 fb 01 48 04 80 0f 84 9e 08
anyway, I powercycled the machine, all is back to normal and now chkrootkit shows nothing strange.
The ups is a cheap one, a 500 model, so maybe that is part of the problem.
Jan 27 12:55:58 tux apcupsd[20605]: apcupsd exiting, signal 15
Jan 27 12:55:58 tux apcupsd[20605]: apcupsd shutdown succeeded
Jan 27 12:56:01 tux /USR/SBIN/CRON[9363]: (root) CMD (/sbin/adslscript)
Jan 27 12:56:09 tux kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000c45
Jan 27 12:56:09 tux kernel: printing eip:
Jan 27 12:56:09 tux kernel: d4ae55a2
Jan 27 12:56:09 tux kernel: *pde = 00000000
Jan 27 12:56:09 tux kernel: Oops: 0000 [#2]
Jan 27 12:56:09 tux kernel: PREEMPT
Jan 27 12:56:09 tux kernel: Modules linked in: ide_cd cdrom evdev pcspkr floppy snd_ens1371 snd_rawmidi snd_seq_device snd_pcm snd_page_alloc snd_timer snd_ac97_codec es1371 gameport ac97_codec aic79xx uhci_hcd
pci_hotplug intel_agp agpgart usbhid nfsd exportfs lockd sunrpc sch_htb sch_ingress cls_fw cls_u32 sch_sfq sch_cbq ppp_deflate zlib_deflate bsd_comp ppp_synctty ppp_generic slhc ipt_REDIRECT ipt_REJECT ipt_rec
ent ipt_length ipt_TOS iptable_mangle usbcore parport_pc lp autofs4 ipv6 genrtc snd_mixer_oss snd soundcore dm_mod capability commoncap 3c59x ipt_conntrack ipt_ULOG aic7xxx st tun loop ip_nat_irc ip_conntrack_i
rc ip_nat_ftp ip_conntrack_ftp parport ipt_mark ipt_state iptable_filter ipt_MARK ipt_MASQUERADE iptable_nat ip_conntrack ipt_LOG ip_tables af_packet ext3 jbd mbcache ide_generic piix ide_disk ide_core sd_mod a
ta_piix libata scsi_mod unix font vesafb cfbcopyarea cfbimgblt cfbfillrect
Jan 27 12:56:09 tux kernel: CPU: 0
Jan 27 12:56:09 tux kernel: EIP: 0060:[<d4ae55a2>] Not tainted
Jan 27 12:56:09 tux kernel: EFLAGS: 00010286 (2.6.8-3-686)
Jan 27 12:56:09 tux kernel: EIP is at hiddev_ioctl+0x32/0x920 [usbhid]
Jan 27 12:56:09 tux kernel: eax: cd44acc0 ebx: 00004802 ecx: ca536800 edx: fffffffb
Jan 27 12:56:09 tux kernel: esi: 00000000 edi: 00000001 ebp: 00000000 esp: c189fef0
Jan 27 12:56:09 tux kernel: ds: 007b es: 007b ss: 0068
Jan 27 12:56:09 tux kernel: Process apcupsd (pid: 9370, threadinfo=c189e000 task=d3f1ef30)
Jan 27 12:56:09 tux kernel: Stack: d37d39c0 00000000 c189e000 cc3e3e60 00000000 d4a41a00 c015e392 d339eb54
Jan 27 12:56:09 tux kernel: d37d39c0 00000103 c9d5e32c d37d39c0 d339eb54 d3fbbaa0 d3fbbaa0 c0153cfc
Jan 27 12:56:09 tux kernel: d37d3a08 d339ebec 71d4d9d3 00000102 0808b7f8 cea9e000 c189e000 c0153be8
Jan 27 12:56:09 tux kernel: Call Trace:
Jan 27 12:56:09 tux kernel: [<d4a41a00>] usb_open+0x0/0x1f0 [usbcore]
Jan 27 12:56:09 tux kernel: [<c015e392>] chrdev_open+0xf2/0x220
Jan 27 12:56:09 tux kernel: [<c0153cfc>] dentry_open+0x10c/0x240
Jan 27 12:56:09 tux kernel: [<c0153be8>] filp_open+0x68/0x70
Jan 27 12:56:09 tux kernel: [<c01681cc>] sys_ioctl+0x11c/0x280
Jan 27 12:56:09 tux kernel: [<c010603b>] syscall_call+0x7/0xb
Jan 27 12:56:09 tux kernel: Code: 8b b7 44 0c 00 00 85 c0 74 64 81 fb 01 48 04 80 0f 84 9e 08
anyway, I powercycled the machine, all is back to normal and now chkrootkit shows nothing strange.
The ups is a cheap one, a 500 model, so maybe that is part of the problem.
[ Parent | Reply to this comment ]
Sorry for the off topic, but:
Are you using the APC 500 model with the RJ11<->USB comm cable?
Have you managed to get apcaccess to work with it, as all I get is a blank hang until I CTRL+C out...
And when starting up the daemon, the logfile states that the apcupsd netserver couldn't bind the the configured port (which could be why apcaccess hangs...)
Any ideas?
Cheers.
Are you using the APC 500 model with the RJ11<->USB comm cable?
Have you managed to get apcaccess to work with it, as all I get is a blank hang until I CTRL+C out...
And when starting up the daemon, the logfile states that the apcupsd netserver couldn't bind the the configured port (which could be why apcaccess hangs...)
Any ideas?
Cheers.
[ Parent | Reply to this comment ]
yes, that Ãs the combo I'm using with a stock kernel for sarge 2.6.
I already noticed that there are some problems with stopping and starting the service, but hey, it works.
At work we have *a lot* of smart ups thingies, and some servers refuse to start if the usb cable is connected. This is a pain with update tuesday, of course.
I already noticed that there are some problems with stopping and starting the service, but hey, it works.
At work we have *a lot* of smart ups thingies, and some servers refuse to start if the usb cable is connected. This is a pain with update tuesday, of course.
[ Parent | Reply to this comment ]