Bug 9542

Summary: top, chkconfig failing to work
Product: [Retired] Red Hat Linux Reporter: Roy Arthur Fish <valankar>
Component: chkconfigAssignee: Bill Nottingham <notting>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: rvokal, sunild
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-03-09 21:16:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Roy Arthur Fish 2000-02-18 03:46:37 UTC
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!

Comment 1 Bill Nottingham 2000-03-07 19:43:59 UTC
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 06:50:59 UTC
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!

Comment 3 Bill Nottingham 2000-03-08 15:17:59 UTC
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 15:18:59 UTC
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.

Comment 5 Roy Arthur Fish 2000-03-09 21:16:59 UTC
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.