Hi there! I recently set up OpenVAS 8 on Kali 1.1.0 and ran into a funny problem.
While running a scan, the Kali VM would use up more and more RAM at
high CPU load until finally crashing. I quickly identified the dirb scanner
as the culprit.
While strace’ing the scanner, I noticed its last action was running stat()
on the cache directory. Then there would just be requests for more and
more RAM.
I noticed that the bug did not occur while running stand alone from the
command line. The one thing different with OpenVAS was that the scanner
was running with HOME=/.
After looking at the source I found a bug in the mkpath() function in resume.c
and in the way the cache directory string is built. If HOME=/, the cache
directory string will end up like //.cache/…
In mkpath(), the recursion exits only if the last directory being returned by
dirname() is either “.” or “/“. But in the special case of HOME=/, the last
directory is “//“. So there’s a nice endless recursion here.
I just added a simple patch to fix the path string when HOME=/
The scanner works ok now.
Kind regards,
Ferdinand
--- dirb222/src/resume.c 2013-12-03 13:17:38.000000000 +0100
+++ dirb222.patched/src/resume.c 2015-07-02 09:35:35.384410838 +0200
@@ -35,7 +35,11 @@
// Comprobamos si existe el directorio y sino intentamos crealo
home = getenv("HOME");
- asprintf(&dumppath,"%s/%s", home, DUMP_DIR);
+ if (strcmp(home, "/") == 0) {
+ asprintf(&dumppath,"%s%s", home, DUMP_DIR);
+ } else {
+ asprintf(&dumppath,"%s/%s", home, DUMP_DIR);
+ }
asprintf(&optionspath, "%s/%s", home, OPTIONS_DUMP);
asprintf(&wordlistpath, "%s/%s", home, WORDLIST_DUMP);
asprintf(&dirlistpath, "%s/%s", home, DIRLIST_DUMP);
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Openvas-discuss mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
