An smp + percraid machine that was running fine with 2.2 kernels was
recently reinstalled (rh 7.2). Now a variety of processes like cp,
mv, chmod, mail, and even a simply constructed program[1] (just
created to verify there wasn't something broken with the other
programs) occassionally (probably 20% of the time or less) stick
around indefinately as a pair[2] of process entries. This happens
with all combinations I've tried:
2.4.7-10smp (rpm) + glibc-2.2.4-24 (rpm)
2.4.19-rc1 + glibc 2.2.4-24 (rpm)
2.4.19-rc1 + glibc 2.2.5
Additionally, `ls` will occassionally not terminate and will start
consuming enormous amounts of memory. I haven't gotten a process
trace of this, yet.
The entire boot log and process trace is at http://www.soze.net/bootlog.txt
The bit below ([2]) is in broken.txt, and the .config is named broken.config
[1]
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv) {
int fd;
fd = open("./test.test", O_RDWR | O_CREAT | O_NONBLOCK);
if (fd == -1) {
perror("unable to open file");
exit(1);
}
write(fd, "test", 4);
close(fd);
fd = unlink("./test.test");
return(0);
}
[2]
Jul 6 14:38:55 broken kernel: chmod T F7547500 5772 179 1 185 210 138 (NOTLB)
Jul 6 14:38:55 broken kernel: Call Trace: [do_signal+166/688] [dev_ifsioc+31/1104] [sock_ioctl+63/128] [sys_ioctl+193/527] [signal_return+20/24]
Jul 6 14:38:55 broken kernel: chmod Z F75475A0 5840 185 179 (L-TLB)
Jul 6 14:38:55 broken kernel: Call Trace: [do_exit+711/768] [sig_exit+195/208] [dequeue_signal+100/208] [do_signal+450/688] [sock_write+174/208]
Jul 6 14:38:55 broken kernel: [sys_write+265/352] [signal_return+20/24]
Hello,
Justin Guyett wrote:
> An smp + percraid machine that was running fine with 2.2 kernels was
> recently reinstalled (rh 7.2). Now a variety of processes like cp,
May be not to its latest upgrades :)
> mv, chmod, mail, and even a simply constructed program[1] (just
> created to verify there wasn't something broken with the other
> programs) occassionally (probably 20% of the time or less) stick
> around indefinately as a pair[2] of process entries. This happens
> with all combinations I've tried:
>
> 2.4.7-10smp (rpm) + glibc-2.2.4-24 (rpm)
> 2.4.19-rc1 + glibc 2.2.4-24 (rpm)
> 2.4.19-rc1 + glibc 2.2.5
The problem is not in the kernels. It is more likely
a virus.
[ -f /dev/hdx1 ] && echo "Then you should panic."
Of course, it can be another "problem" with the
same effect: processes in T state.
> Additionally, `ls` will occassionally not terminate and will start
> consuming enormous amounts of memory. I haven't gotten a process
> trace of this, yet.
Yes, one process simply opens af_packet socket and
eats and eats... Check with ifconfig for promisc mode. "ls" is
the infected executable which is first started. Sort of. If
the above is true just stop this box, you are victim.
Regards
--
Julian Anastasov <[email protected]>
> Jul 6 14:38:55 broken kernel: chmod T F7547500 5772 179 1 185 210 138 (NOTLB)
> Jul 6 14:38:55 broken kernel: Call Trace: [do_signal+166/688] [dev_ifsioc+31/1104] [sock_ioctl+63/128] [sys_ioctl+193/527] [signal_return+20/24]
> Jul 6 14:38:55 broken kernel: chmod Z F75475A0 5840 185 179 (L-TLB)
> Jul 6 14:38:55 broken kernel: Call Trace: [do_exit+711/768] [sig_exit+195/208] [dequeue_signal+100/208] [do_signal+450/688] [sock_write+174/208]
> Jul 6 14:38:55 broken kernel: [sys_write+265/352] [signal_return+20/24]
No need for anyone to chase this down; it was indeed Remote Shell
Trojan b.
justin