On Mon, 14 Feb 2000, Michael Balzer wrote:
dear fellow admins, dear marc,
i installed some suse 6.3 "sec" packages, among others marc's /usr/lib/secchk scripts and john (weak passwd checker).
last evening, john used cpu ressources i needed myself, so i tried to kill him, assuming he would listen to my wishes ;-). well, he didn't, but instead started to fork himself over and over again, exiting the father as soon as the child became functional.
i consider this a normal hacker/cracker programming technic in order to avoid being killable by just one pid. but i don't consider this a normal behaviour for any program meant to be used for normal system management by an authorized admin.
There may well be programs that try to recover from errors with something like this. It might be that while you changed the system some process of john was left in a curious limbo state. Did you update your system while in simgle user mode, didn't you. Well doing security while online with multiple users online is not good practise.
maybe i'm wrong (didn't check the sources), but if so, this is still a serious bug.
SECOND. i had to shutdown to stop john from eating up all ressources. now after reboot, most applications (i.e. "ls", "su", "xterm", "xtelnet", "xlogin" ...) refuse to work from a normal user account. "xterm" for example establishes the connection with the X server and then crashes with a bus error. "ls" and "su" immediately crash with a bus error.
It seems the files have been tampered with. This might also result from an unclean shutdown leaving some or all filesystems mounted read/write while rebooting. Have you considered this behavior being created by some part of filesystem activity. It might well happen if you tried to kill some 'child' which was for example doing write operations to unreachable filesystem part ( which by the way turned unwriteable by the security scripts for example ). The parent might just had being 'retrying' for the critical write operation. Anyway. Never make major system changes on live systems. Security should - in my opinion - be changed only while in single user mode. -Pete
but all of these work perfectly when running as root, so i guess the security checking scripts damaged some file access rights because they have been stopped before their normal termination.
can anyone (marc!?) tell me which files may be corrupted in what way to produce such an effect?
i already executed the scripts again, but nothing changed.
regards, michael balzer -- b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com