You've gone to a lot of effort -- have you sent that to the Tenable folks? It's well beyond my experience and they /are/ the experts :)
--- Original Message --- From:"Mark Frost" <[EMAIL PROTECTED]> Sent:Thu 2/22/07 6:02 pm To:"[email protected]" <[email protected]> Cc: Subj:Nessusd Segfaults 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 mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
