secchk package / stopping john / help!
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. 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. 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
Hi, On Mon, 14 Feb 2000, Michael Balzer wrote:
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.
maybe i'm wrong (didn't check the sources), but if so, this is still a serious bug.
It's not a bug - it seems like john spawns multiple tasks/threads to parallelize the search. If you want to kill multiple processes at once, try "killall". E.g., in your case you could have used "killall john", to regain control of your box. Alternatively you can try to determine the father process that forks the child processes - if you kill this one, it's childs should be terminated too.
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.
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.
This sounds odd. Unfortunately I have no idea, what John might have done wrong there, so I cannot give you a hint on that one :( Sorry. Bye, LenZ -- ------------------------------------------------------------------ Lenz Grimmer SuSE GmbH mailto:grimmer@suse.de Schanzaeckerstr. 10 http://www.suse.de/~grimmer 90443 Nuernberg, Germany
hi lenz,
It's not a bug - it seems like john spawns multiple tasks/threads to parallelize the search. If you want to kill multiple processes at once, try "killall". E.g., in your case you could have used "killall john", to regain control of your box. Alternatively you can try to determine the father process that forks the child processes - if you kill this one, it's childs should be terminated too.
killall did not work, and there was no father process which i could get my hands on, because every john just immediately spawned a new john and terminated. i think the reason, killall didn't work, was because this spawning happened too fast for killall. regards, michael balzer -- b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
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
hi petri,
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.
marc's secchk scripts are started automatically daily, weekly and monthly. they are not supposed to change any vital settings, but only to check for and report potential problems.
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.
how would this explain that everything's running fine when logged in as root? regards, michael balzer -- b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
hi, i do not believe that i run any of the scripts you mentioned, but i experience exactly same symptoms with xterm since some time ago --> only root can run it (xterm permissions are -rwsr-xr-x 1 root root ) bye, -alexm On Mon, 14 Feb 2000, Michael Balzer wrote:
hi petri,
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.
marc's secchk scripts are started automatically daily, weekly and monthly. they are not supposed to change any vital settings, but only to check for and report potential problems.
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.
how would this explain that everything's running fine when logged in as root?
On Mon, 14 Feb 2000, alex medvedev wrote:
i do not believe that i run any of the scripts you mentioned, but i experience exactly same symptoms with xterm since some time ago --> only root can run it (xterm permissions are -rwsr-xr-x 1 root root )
Hi, perhaps a problem with wrong permissions in /dev/pty* or /dev/pts/* ? Sometime ago, I couldn't start xterm and a change of the /dev/pt??? permissions in /etc/fstab solved the problem but I forgot the details... :( Cheers, Peter -- Peter Münster **** Brittany **** France URL: http://gmv.spm.univ-rennes1.fr/~peter/
Hello, Maybe you could have tried 'killall -KILL john' in order to kill all "john"-Processes. You don't have to specify the PID(s) then. On Mon, 14 Feb 2000, Michael Balzer wrote:
... 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. ...
Regards, Martin Leweling -- Martin Leweling Institut fuer Planetologie, WWU Muenster Please sign the Linux Driver Petition on http://www.libranet.com/petition.html
hi martin,
Maybe you could have tried 'killall -KILL john'
neither that one nor the variant using the complete path worked. regards, michael balzer -- b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
participants (6)
-
alex medvedev -
Lenz Grimmer -
Martin Leweling -
Michael Balzer -
Peter Münster -
Petri Sirkkala.