On Wed, 18 Aug 2004, Steve Bonds sxm4qcu02-at-sneakemail.com |nessus| wrote:
If the problem recurs I'll be sure to investigate and post more details.
Alas, the problem has recurred. This has been a tricky one to sort out
since there are two symptoms.
Symptom 1:
+ incorrect text shown for the holes found
Symptom 2:
+ no security holes/warnings found even though they're present
In the nessusd.dump file I see LOTS of lines like:
-----
[15749] Could not allocate a pointer of size 131073 !
malloc: Cannot allocate memory
[15751] Could not allocate a pointer of size 10 !
malloc: Cannot allocate memory
malloc: Cannot allocate memory
malloc: Cannot allocate memory
malloc: Cannot allocate memory
malloc: Cannot allocate memory
[15757] Could not allocate a pointer of size 29 !
[15758] Could not allocate a pointer of size 29 !
-----
These correspond to these lines in nessusd.messages (IP address hidden):
-----
[15623] user sbonds : launching shoutcast_log_xss.nasl
against W.X.Y.Z [15749]
[15623] shoutcast_log_xss.nasl (process 15749) finished its
job in 0.237 seconds
[15623] user sbonds : launching sharemailpro_username_identification.nasl
against W.X.Y.Z [15751]
[15623] sharemailpro_username_identification.nasl (process 15751)
finished its job in 0.212 seconds
[15623] user sbonds : launching imap4_banner.nasl
against W.X.Y.Z [15757]
[15623] imap4_banner.nasl (process 15757) finished its job in
0.214 seconds
[15623] user sbonds : launching bind_allows_updates.nasl
against W.X.Y.Z [15758]
[15623] bind_allows_updates.nasl (process 15758) finished
its job in 0.219 seconds
-----
Once one plugin has this problem, it appears that all subsequent plugins
have the same problem.
At first, I thought this might be because I had built the binaries on a
Pentium 4 system, then copied the RPMs to a Pentium II system. Sometimes
"-O6" can do strange things to binary portability. :-)
Unfortunately, my latest build of 2.0.12 was on the same system where the
nessusd server is running. I also built the 2.0.12 client local to the
system where it will be running. (Red Hat Enterprise Linux WS 3, kernel
2.4.21-15.0.4.EL)
My next guess was that perhaps Nessus drove the system out of memory,
however this is what /proc/meminfo looks like after the messages start:
-----
total: used: free: shared: buffers: cached:
Mem: 327303168 158203904 169099264 0 5988352 61304832
Swap: 536862720 18440192 518422528
MemTotal: 319632 kB
MemFree: 165136 kB
MemShared: 0 kB
Buffers: 5848 kB
Cached: 47048 kB
SwapCached: 12820 kB
Active: 85568 kB
ActiveAnon: 50620 kB
ActiveCache: 34948 kB
Inact_dirty: 12468 kB
Inact_laundry: 1868 kB
Inact_clean: 2020 kB
Inact_target: 20384 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 319632 kB
LowFree: 165136 kB
SwapTotal: 524280 kB
SwapFree: 506272 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
-----
Getting desperate, I tried an strace on the plugins as they were executed.
The first failure looked like this (last bit of the strace):
-----
getcwd("/", 4096) = 2
chdir("/usr/lib/nessus/plugins") = 0
open("/usr/lib/nessus/plugins/shoutcast_log_xss.nasl", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0444, st_size=1632, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb75e9000
read(4, "#\n# (C) Tenable Network Security"..., 4096) = 1632
open("http_func.inc", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0444, st_size=10871, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb75e8000
read(5, "# -*- Fundamental -*-\n#\n# (C) 20"..., 4096) = 4096
brk(0) = 0x820f000
brk(0x8230000) = 0x820f000
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x401 (flags O_WRONLY|O_APPEND)
close(7) = 0
fstat64(2, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb5cda000
write(2, "malloc: Cannot allocate memory\n", 31) = 31
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(18850, 18850, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
-----
What else should I look at? I'm not afraid of getting my hands dirty
sorting out the problems with Nessus, but I'm not sure quite where to go
from here. Boosting the debug level on the client side doesn't seem to
provide more info.
-- Steve
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
