uptime, top, w and who: incorrect users info

pdi · 07-08-2008, 01:06 AM

When only one user is logged in the commands top, uptime, w and who report more than one logged in user.

This seems to be utmp-related. After a reboot, or after a purging of utmp by some other method, the commands report correctly but only for a little while.

According to other postings, it seems to be an issue going back at least to Slackware 8. Hopefully it is not a security issue.

Gathered below are the threads I found here on this issue.
finger shows logged in to console tty1 even after logging out
running top shows 2 users
who showing users that arent logged on
incorrect usercount reported by w and top
uptime cmd shows 5 users but thats wrong
users stays logged in
user with no logout
uptime 0 users

A possible explanation has to do with glibc:
Programs like `logname', `top', `uptime' `users', `w' and `who', show incorrect information about the (number of) users on my system. Why?

If this is indeed the root of the matter, do we wait it out? Is it only an annoyance, or are there possible security implications?

Best regards,
pdi

unSpawn · 07-08-2008, 08:15 PM

IMHO the best way to make sure would be to check the original package site for bug tickets and Securityfocus, Secunia, et cetera

If it's not about providing false information, in the sense that malformed, false details get recorded, then only applications that make decisions based on record info (say write to certain tty) are "at risk". Since it's "just" about duplicated records (which doesn't sound good to me either, OK) risks look low. If there's a fix then why wait it out unless there's a clearly communicated ETA you can live with?..

ghostdancer · 07-10-2008, 05:20 AM

Maybe the system has been compromised?

I don't have such problem here. My oldest Slackware is 11. Slackware 8 is really very old, IIRC, it was released sometime around year 2001.

pdi · 07-10-2008, 06:33 AM

@unSpawn
1. I'm being rather dense, I still can't locate the package utmp belongs to.
2. Could you please give an example of an application that might be at risk?

@ghostdancer
A compromise was the first thought. But it happens even when the router is down and the server rebooted. Occasionally logging in and out of a tty may clear some entry. In addition chkrootkit was run from a live CD and reported nothing as `INFECTED'. I run across no other peculiar symptoms. Lastly, googling for `utmp bug' brings many reports on this on various distros.

unSpawn · 07-10-2008, 07:54 AM

Quote:

Originally Posted by pdi

I still can't locate the package utmp belongs to.

I doubt it belongs to some single package as it's used by a lot. Maybe check the package(s) "rc.S", 'init' and 'login' belong to?

Quote:

Originally Posted by pdi

Could you please give an example of an application that might be at risk?

I said "at risk" meaning risk shouldn't be taken as a threat, something concrete, because that would mean having audited the code. I can't give you a list (for that see upstream, Slackware security advisories, Securityfocus, Secunia) but to find out yourself what reads utmp is easy (even though you probably won't be able to mimick it this way for not running the Audit daemon there are other ways), first I'll set a watch to see what accesses and writes to utmp:

Code:

auditctl -w /var/run/utmp -p wa -k UTMP

, then after some time I'll issue:

Code:

syscallNum2Name () { grep "^#define __NR_.*[[:blank:]]$1$" /lib/modules/$(uname -r)/build/include/asm-i386/unistd.h \
| awk -F'_' '{print $4}'; }; ( echo 'syscall application'; awk '/^type=SYSCALL.*UTMP/ {print $4, $25}' /var/log/audit/audit.log \
| sort | uniq | while read syscall exe; do syscall=($(syscallNum2Name ${syscall//*=/})); exe=${exe//exe=/}; \
echo "${syscall[0]} ${exe}"; \done )|column -t

which after five minutes yields (cleaned up):

Code:

syscall application
open    ku
open    su
open    screen
open    xterm
open    utempter

pdi · 07-11-2008, 09:22 PM

unSpawn,

Thank you for your explanation. Quite a lesson!
I'll come back if I find something new.

Best regards,
pdi