First I have to say I'm not sure what is causing this problem but I suspect that the problems are related. The troubel turned up on two of my Red Hat Linux boxes (This one and the DNS server at work) on the same day. (Feb 15) Symtoms : 0=---------------=~=---------------=0 top fails reporting an error I can't see because it flashes by so fast (See below) I can repair top for an unknown time by removing all data with pico in the /var/run/utmp file. (I have the origional) the 'corrupt' utmp file contains the following ^H ^K8bl^N^KAm 8^S^K Note: the A above is not a standard A characture it's one of the special ANSI charactures.. issuing top >file allows me to see the output which is as follows.. bad data in /var/run/utmp From that moment on the terminal becomes weird and I can not see the commands I type intill I logout (From a telnet session) or exit and start another session from x. ktop is not affected. 0=---------------=~=---------------=0 ps ps -A reports the following unreconigized option or trailing garbage Then the standard general help screen. My man files appear to be in order. ps -a works as expected ps --version reports procps version 1.01 0=---------------=~=---------------=0 cron/chkconfig Sends root a email every hour as follows... Subject: <Cron> root@dev run-parts/etc/cron.hourly Body: cannot determine current run level Attempts to run the script in /etc/cron.hourly (inn-cron-nntpsend) fails with the same message. Manualy running this script does not cause top to fail. the file contains the following.. #/bin/sh /sbin/chkconfig innd && su - news -c /usr/bin/nntpsend The file exists (/usr/bin/nntpsend) on this computer .. however running simply 'chkconfig innd' reports the same error. I have verified that the nntp server is running on the pid specified in the /var/run/nntp directory. 0=---------------=~=---------------=0 Help!
It sounds like you have a program writing bogus data to the utmp file; are you running any daemons linked against libc5?
Hi, I am running Oracle which if I recall correctly required a special patch for glibc5. I am experiencing the exact same problem with top, and I believe it started after y2k (just a guess but close to this time frame). Does this sound like the culprit? Would RH 6.1 have this same problem, I also noticed that you guys have an edition of RH tailored for Oracle 8i. Thanks in advance for any input!
libc5 isn't the same thing as glibc. Basically, the format of the utmp file changed between libc5 (the C library used in RH4.2) and glibc (the C library used in RH5.2 and onward.) Hence, any older programs trying to write to it can corrupt it.
Also, there is always the possibility that the utmp/wtmp files have been changed by some sort of remote attack; while this is probably not the case, it is something to keep in mind.
Ick.. Well here goes. The troubles I reported were caused by an attack.. Specifically caused by the installation of what I believe is known as a root kit. The cracker basically destroyed all of the logging system after he installed modified ps, top, inetd and chkconfig.. In addition the cracker may have installed other back doors that I did not detect. In the end I gave up the search and decided to fdisk the hard drive and start over only saving vital data. It is my belief that the attacker wanted a launching platform for other attacks. I saw no evidence of a client that was waiting to launch a ddos however it may have been inactive or configured for a unusual port. This machine hosts a couple of games and some simple not for profit web pages and serves as a small DNS server for my home network, so the attacker could not have gotten anything other than its computational resources. (Read : nothing to steal!) All passwords have been changed after the reinstall and all software has been upgraded as per the Redhat.com site. In addition Ive installed a version of Open SSH ( http://www.openssh.com ) and am using Teraterm ( http://hp.vector.co.jp/authors/VA002416/teraterm.html ) and the SSH plugin (http://www.zip.com.au/~roca/ttssh.html ) now for added security in addition to installing logwatch (http://www.kaybee.org/~kirk/html/linux.html ) to hopefully keep on top of suspisious events and connections. It is my belief that the cracker gained root by exploiting the older NNTP server I had left installed and running even thou I wasnt using it. Additional Ive modified inetd.conf removing all unnecessary services.