I tried to do a ps recently and got the following error: [rebuke@Linux rebuke]$ ps -ef | grep squid ps: can't load library 'libc.so.5' Any ideas?
On Fri, Mar 02, 2001 at 11:18:36AM -0000, Alex Brett wrote:
I tried to do a ps recently and got the following error:
[rebuke@Linux rebuke]$ ps -ef | grep squid ps: can't load library 'libc.so.5'
Any ideas?
Do: # updatedb $ locate libc.so.5 If those commands don't work or locate doesn't find the library then it suggests that for some reason that library has disappeared and you have to re-install it. How you do that is of course dependent on your distribution. -- Frank *-------*-----*-----*-----*-----*-----*-----*-----*-----*-------* | Boroughbridge | Tel: 01423 323019 | PGP keyID: 0xC0B341A3 | *-------*-----*-----*-----*-----*-----*-----*-----*-----*-------* http://www.esperance-linux.co.uk/
I'm posting this purely as a cautionery note, and it may or may not relate your problem. An friend of mine has had a similar problem on his firewall system. Also, some services stop working - probably library based, and people have had trouble logging into the system. Today, it was finally tied down to the fact that someone had broken into his system - probably through bind, although he was running a recent version, 8.2.2-P3. The problems were apparent, because a number of the commands, such as 'ps' and 'ls' had been replaced by versions compiled on another box. For those who wish to check, try to cd into #/usr/src/.puta. Don't try to 'ls' it because it won't show it. Apparently, the 'cd' command hasn't been altered, presumably because the cracker needed it to get back all the user ID/passwords it was harvesting every time popd, telnetd etc. was used. On Friday 02 March 2001 11:18 am, Alex Brett wrote:
I tried to do a ps recently and got the following error:
[rebuke@Linux rebuke]$ ps -ef | grep squid ps: can't load library 'libc.so.5'
Any ideas?
-- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
Hi, On 2 Mar 2001, at 19:31, Gary Stainburn wrote:
I'm posting this purely as a cautionery note, and it may or may not relate your problem.
An friend of mine has had a similar problem on his firewall system. Also, some services stop working - probably library based, and people have had trouble logging into the system.
These kind of problems have been reported on various Security ( especially Cobalt RaQ ) mailing lists about problems with telnet and logging in to Linux boxes.
Today, it was finally tied down to the fact that someone had broken into his system - probably through bind, although he was running a recent version, 8.2.2-P3.
In BIND terms that's ancient, when the box is rebuilt it should be running 8.2.3, if not 9.<whatever is safe now>. Though please don't take my word for it, check www.isc.org for the latest details.
The problems were apparent, because a number of the commands, such as 'ps' and 'ls' had been replaced by versions compiled on another box.
This is commonly known as a "rootkit", because it allows a hacker to hide the alterations they've made to the host. There are various different ones available, which means:
For those who wish to check, try to cd into #/usr/src/.puta. Don't try to 'ls' it because it won't show it. Apparently, the 'cd' command hasn't been altered, presumably because the cracker needed it to get back all the user ID/passwords it was harvesting every time popd, telnetd etc. was used.
this won't necessarily show whether the host has been hacked or not. Try comparing the output of netstat and ps with the output of lsof and sockstat if you have them; and a scan of the box externally, to see if netstat and ps have been compromised. Also look in /dev and /proc for unusual files and directories, especially those starting with a dot. Also, while I haven't used it myself, I've heard generally good things about chkrootkit at http://www.chkrootkit.org/. And compare MD5 checksums with known good binaries on a known good box, or even those off an install CD. Oh, and check the contents of inetd.conf ( especially the end ), and check inetd is using /etc/inetd.conf for it's config and not "/usr/games/buried away in some obscure directory/.hidden/.hackers.special.full.of.holes.inetd.conf" instead. And after all that, you still can't be sure, but it's a start :( -- "Never attribute to malice that which can be adequately explained by stupidity." http://www.tuxedo.org/~esr/jargon/html/entry/Hanlon's-Razor.html
participants (4)
-
Alex Brett -
Frank Shute -
Gary Stainburn -
Nick Drage