Bug 9542 - top, chkconfig failing to work
top, chkconfig failing to work
Product: Red Hat Linux
Classification: Retired
Component: chkconfig (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2000-02-17 22:46 EST by Roy Arthur Fish
Modified: 2014-03-16 22:12 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-03-09 16:16:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Roy Arthur Fish 2000-02-17 22:46:37 EST
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 :


fails reporting an error I can't see because it flashes by so fast (See

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
^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.


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


Sends root a email every hour as follows...

Subject: <Cron> root@dev run-parts/etc/cron.hourly

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

the file contains the following..
/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.


Comment 1 Bill Nottingham 2000-03-07 14:43:59 EST
It sounds like you have a program writing bogus data
to the utmp file; are you running any daemons linked
against libc5?
Comment 2 Sunil 2000-03-08 01:50:59 EST
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
Comment 3 Bill Nottingham 2000-03-08 10:17:59 EST
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.
Comment 4 Bill Nottingham 2000-03-08 10:18:59 EST
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
Comment 5 Roy Arthur Fish 2000-03-09 16:16:59 EST
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

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

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.

Note You need to log in before you can comment on or make changes to this bug.