@7a : I noticed that with the w3af “finding buffer overflows in web apps” tests, w3af tends to crash due to lack of memory, OWTF however, appears to fail to close these processes sometimes:
When the closure fails, the 1st time it does not seem to do anything:
i.e. you click on the close button for the worker, but the same task is displayed after waiting.
The 2nd time, OWTF does move on to new tasks, however, the previous task remains open, in this case w3af, taking 40% of my RAM after a crash
The children process clean-up needs to be revisited to solve this problem.
Dead children processes:
root 6671 18701 0 Mar06 ? 00:00:00 /bin/sh -c cd owtf_review/targets/http__some.host.com/partial/W3Af_Unauthenticated/active; /root/owtf_develop/scripts/run_w3af.sh /usr/share/w3af/w3af_console http://some.host.com 127.0.0.1:8008 'Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/15.0'
root 6672 6671 0 Mar06 ? 00:00:00 bash /root/owtf_develop/scripts/run_w3af.sh /usr/share/w3af/w3af_console http://some.host.com 127.0.0.1:8008 Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/15.0
root 6683 6672 88 Mar06 ? 14:39:31 python /usr/share/w3af/w3af_console -n -s w3af_report2015-03-06_22_05_11.script.w3af
Manual fix:
I killed the w3af process, and let the OWTF wrapper scripts do their job with the hope of saving some results out of the scraping from w3af despite the crash. All of which was OK running this command (see PIDs above):
kill -9 6683
NOTE: -9 might be unnecessary, I just tried that straight away
@7a : I noticed that with the w3af “finding buffer overflows in web apps” tests, w3af tends to crash due to lack of memory, OWTF however, appears to fail to close these processes sometimes:
When the closure fails, the 1st time it does not seem to do anything:
i.e. you click on the close button for the worker, but the same task is displayed after waiting.
The 2nd time, OWTF does move on to new tasks, however, the previous task remains open, in this case w3af, taking 40% of my RAM after a crash
The children process clean-up needs to be revisited to solve this problem.
Dead children processes: root 6671 18701 0 Mar06 ? 00:00:00 /bin/sh -c cd owtf_review/targets/http__some.host.com/partial/W3Af_Unauthenticated/active; /root/owtf_develop/scripts/run_w3af.sh /usr/share/w3af/w3af_console http://some.host.com 127.0.0.1:8008 'Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/15.0' root 6672 6671 0 Mar06 ? 00:00:00 bash /root/owtf_develop/scripts/run_w3af.sh /usr/share/w3af/w3af_console http://some.host.com 127.0.0.1:8008 Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/15.0 root 6683 6672 88 Mar06 ? 14:39:31 python /usr/share/w3af/w3af_console -n -s w3af_report2015-03-06_22_05_11.script.w3afManual fix:
I killed the w3af process, and let the OWTF wrapper scripts do their job with the hope of saving some results out of the scraping from w3af despite the crash. All of which was OK running this command (see PIDs above):
kill -9 6683