I had written some scripts to automate my nessus usage, and I began to
notice terrible segfault issues. The warnings began to appear roundabout
the time 3.0.2 came out, but I believe it was happening beforehand, it
just wasnt being verbose about it. I have always noticed Nessus seems to
not always scan some of the hosts I tell it to, and it seems as though
this is related. I am now using Nessus 3.0.5, and the problem persists.
Anyway, the visible output I get looks something like this:
*** The daemon shut down the communication
Connection closed by the server (SIGPIPE caught)
send: Broken pipe
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send: Success
send : Success
Various things about that seem strange to me. I dont understand why the
first one is a broken pipe, whereas the rest arent, and I DEFINITELY
dont understand why that last send has an extra space before the colon
(this is consistent. Every time this error occurs, the last send message
is formatted in that way.
After a great deal of extra debugging, I eliminated consistency. It
didnt always happen on particular hosts. Which hosts it happened on was
completely random. whether the host was up or down didnt matter.
Perusing through my nessusd.messages, I noticed a pattern like this
every time the broken pipe error happened:
[Thu Feb 22 18:11:49 2007][8449] Client requested protocol version 12.
[Thu Feb 22 18:11:49 2007][8449] successful login of nessusuky from
172.24.164.94
[Thu Feb 22 18:12:10 2007][8449] SIGSEGV occured -- trying to dump the
current environment
[Thu Feb 22 18:12:10 2007][8449] -> dump the process code in
/opt/nessus/var/nessus/logs/nessus_process_dump.8449
Always within about 10-15 seconds, and no plugins are ever running.
Every time this happens, there is a corresponding nessusd.messages log
that matches that EXACTLY, line by line. Due to the rapidness of the
denial (it takes more than 10 seconds for most of my good scans to even
start running their first plugin), I began to suspect it was a
connection error. However, my clients and my server both run from the
same place. Im not doing anything remotely, therefore there shouldnt
really be connectivity issues, I shouldnt think. I dug deeper, and began
experimenting with trying to reproduce the error by hand. I have failed
at this repeatedly, but finally managed to make it happen consistently.
...sort of.
If i open 4 terminals, and connect them all to my server, and tell them
all to connect to the nessus daemon, each using a different config,
output, and targets file, they work. Usually. Unless I try to execute
them all rapidly in succession. The only way to get them to work while
guaranteeing that there wont be a SIGSEGV is to leave about 15 seconds
of lag time in between the launching of each client.
However, as I increase the number of hosts up to 9, I begin to have
problems even at 15 seconds apiece between entering the clients. Also, I
notice a strange correlation. I will hit enter on one client, and it
will hang for about 5 seconds. then, a client which I started about a
minute ago will suddenly display its first output for the first plugin
it's running. At the exact same moment this output appears, the new
client I tried to input throws the "Communication closed by server"
error. In time, the rest follows.
This is not a plugins problem. I have had this problem persist not only
between various installation of nessus, but across various servers as
well. I have ran it on OS's Fedora Core 3 up through Fedora Core 6, and
am on the newest Linux kernel, and have had the problem follow me
without changing in form. I am running a system with 2 dual-core Intel
Xeon 3.4 Gigahertz processors.
I have scanned over my dumps for these SIGSEGV'd processes. They are
virtually identical every time this happens. There are no significant
differences from one to the next, so I have attached a representative dump.
I would LOVE to know what is going on here. It has been driving me crazy
for months now. I would like to know what is causing this to happen, and
what my options are. It seems to me that there is some sort of a race
condition happening in the daemon, but that's all that I can tell.
Further investigation is impossible, due to the now closed-source nature
of the project, and my own lack of understanding of the dump files. I
would like very much to find a way to prevent this from happening, or to
have it repaired in an upcoming version, so that I can continue to use
nessus in the way that I am now, without having to doubt the consistency
of the results returned to me. As it scans, for every 10 scans I launch
within the same 1 minute period, I will generally get a random 5 results
back. I have also had it segfault on ALL of the live hosts, telling me
there were no machines on a subnet, which I know is incorrect, since
previous scans very clearly found machines there.
Your time and effort (or simply shared wisdom, if this is already know
about) would be GREATLY appreciated by both myself and my sanity.
--
Mark B. Frost
[EMAIL PROTECTED]
IT Security
University of Kentucky
859-257-5603
Nessus Dump File -- Thu Feb 22 16:10:25 2007
SIGSEGV dump (Process 4670)
si_code = 1 (SEGV_MAPERR)
si_addr = 0x2bf
Registers :
EIP = aef1af
ESP = bfab67e0
EDI = 58
ESI = 0
EBP = bfab6818
EAX = 2bb
EBX = afa430
ECX = 997d7a4
EDX = 98ce308
Stack :
Backtrace:
8051ee7
e5c440
aedb37
ae6737
ae6def
804fb94
804ff7f
805be05
805229e
805ac96
805ccd6
35df2c
804da41
0x98ce308
0x98ce310
0x0
0x98ce308
0x98ce308
0x0
0x0
0x0
0x98ccaf8
0x98ccaf8
0x0
0xbfab70bc
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x28
0x480ff4
0x3afece
0x5d
0x5d
0xafa430
0x0
0x9ac6f80
0x9ac6fc8
0x1
0x9971bd0
0x9ac6f48
0x9ac6f80
0x808e79f
0x9de2da0
0xa1c1510
0x0
0x98cdcd0
0x98cdcd0
0x9930fe0
0x98cdcd0
0x9930fe0
0x9a0d188
0x0
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
