SliTaz Forum
You are not logged in.
Pages: 1
Hi,
Just recently I noticed the
"Unknown HZ value! (53) Assume 100"
message in by boot.log.
Upon checking on the Net, I found that this could be a sign that the system is being hacked.
http://www.bigismore.com/web-server-security/unknown-hz-value-assume-100-youve-been-hacked/
I then installed chkrootkit and ran the program and got the following output.
"Checking `login'... INFECTED" (full output of chkrootkit attached)
which indicates the /bin/login file is infected.
Any suggestions on how to fix this problem? Thanks
Offline
Hmm ... interesting. I just ran chkrootkit (0.48) over my customized SliTaz 3.0 Live CD and found that BusyBox (1.12.0) login is also identified as INFECTED. Very strange. I do hope there's a harmless explanation for this ...
(EDIT: a little bit later)
Something similar has been reported here over 3 years ago. It turned out to be a false positive caused by poor detection strategy of chkrootkit, which apparently "doesn't like" BusyBox and its use of symlinks. Let's hope this is so.
Offline
I hope so too....
Looks like my chkrootkit log was not attached earlier...here it is again.
Offline
It's a false positive because chkrootkit believes symlinks to login means the system has been rooted.
Also the above report is only caused by a replaced top command and appears whenever top is used. Top in this case is also provided by Busybox and clearly not the cause here. There's a lesser known (mostly because everybody is going 'ZOMG HAX!' because the above report) cause by procps not being compatible with user_hz in the kernel because it was compile with eglibc. This is also probably not the cause (since yet again ps is provide by busybox), but it's probably more in the right direction. My guess? Busybox (or one of the boot programs) isn't completely compatible with the current kernel's user_hz because it was compiled against eglibc - it seems like the obvious cause.
Offline
Hello Gdesilva, same advertence ("Unknown HZ value! (53) Assume 100") in my PC.
I resolved this issue setting Time zone configuration to my country, the default TZ (UTC) is what trigger the advertence...
I forgot to say that so that the hour of the clock is the correct one you should add (as root user) the following line at the end of the file /etc/local.sh:
hwclock --hctosys
Best regards...
Good fix Robertux! 
Offline
@Robertux, I did have my TZ set to local time and not UTC. Tried with the /etc/local.sh as per your suggestion but keep getting the same message albeit with a slightly different HZ value.
I did more checking and found out that it is quite likely a false positive as suggested by Trixar above.
One useful link was to check whether chkrootkit has returned a false positive can be found here.
https://forums.gentoo.org/viewtopic-t-326062-highlight-suckit.html
I ran the tests as suggested here and if the tests are conclusive proof then this is a false positive.
As Trixar suggested it appears to be a problem with procps which has been identified as an issue by the Slackware community and a fix supposed to have been found as per the link below.
http://www.linuxquestions.org/questions/slackware-14/slackware-13-37-rc-unknown-hz-value-after-procps-upgrade-871679/
Offline
Just for the record, I ran chkrootkit in one of my laptops running Slitaz 5 rc3 but which was not updated for about 4 weeks now.
On this laptop I do not get the Unknown HZ value message and chkrootkit does not return an error with /bin/login program either.
So it seems that a recent update, I guess to busybox (that is the only one I recall being updated recently but I may be way off the mark here), that is causing this issue.
Will update this machine and report back.
EDIT :
My laptop was last updated 15 days ago. Recharged and updated hoping that I would be able to replicate the problem but no such problem was reported after the update.
The only other difference I noticed was that the system I am having the problem was set to POSIX locale while the laptop was set to en_AU. Changed the locale of the former to en_AU but the error message still appears.
The only other difference is that I had to load toolchain and linux source in the first machine to compile the proprietary nVidia driver which is not in use in the second.
I am reasonably confident that this is not a major problem after doing the tests but would be nice to be able to isolate the issue.
Any suggestions will be greatly appreciated but I will close this post for now.
Thanks everyone.
Offline
Pages: 1
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.55 MiB (Peak: 1.77 MiB) ]