Mailing List Archive: denial of service semi-false positives

denial of service semi-false positives

Feb 18, 2005, 11:37 PM

Post #1 of 3 (486 views)

I was trying to track down a semi-false positive in a nessus scan and I think I've found an answer that makes enough sense.

The problem I was trying to find is that nessus reported four different ways that cause a web server to crash. Of course the first thing I did was check whether the web server was still running - it was not. But since it doesn't restart automatically, how is it possible that FOUR different plugins are claiming credit for having crashed it?? I've pretty sure I had Denial of Service enabled, safe checks disabled, and optimization off. So especially with no safe checks, there shouldn't be any plugins simply checking version headers and saying that they WOULD HAVE been able to crash it - they should only report if they were actually able to crash it.

So my next thought was, check the scripts, maybe these authors were lazy and didn't put in different messages/actions for safe checks. But I was wrong, without safe checks they didn't shortcut on headers/version information, and they seemed to check the port before and after the attempt.

So I ran nessus again, and eliminated two of the attacks by hand - server servived. Nessus did crash it again though, but the second time nessus reported a different set of plugins that crashed it (one of the same and one new one) and suddenly it dawned on me... Nessus runs multiple plugins in parallel. So what would happen if there was a race condition, so that whichever Denial-of-service plugins were in the process of running at the time any of them crash the service - they would all notice the service went down during their run and take credit for it.

So is there any serialization for denial of service plugins?

Thanks

Re: denial of service semi-false positives [ In reply to ]

mikhail at nessus

Feb 19, 2005, 7:36 AM

Post #2 of 3 (473 views)

Permalink

On Fri, 2005-02-18 at 22:37 -0800, Don Kitchen wrote:

> So my next thought was, check the scripts, maybe these authors were lazy

Maybe.

> and didn't put in different messages/actions for safe checks.

There is another potential false positive generator: the script must
make sure that the service is alive before testing it.
What scripts were responsible for the FP?

Re: denial of service semi-false positives [ In reply to ]

don at n2

Feb 20, 2005, 12:52 AM

Post #3 of 3 (476 views)

Permalink

Michel Arboi wrote:
> > and didn't put in different messages/actions for safe checks.

> There is another potential false positive generator: the script must
> make sure that the service is alive before testing it.
> What scripts were responsible for the FP?

Three of the scripts that came up were argosoft_dos, ws4d_overflow, and
sambar DoS. I've cut and pasted the before and after checks for these:

11734 argosoft_dos
if(! get_port_state(port)) exit(0);
if (http_is_dead(port: port)) exit(0);

11560 ws4d_overflow
if(! get_port_state(port)) exit(0);
if(http_is_dead(port:port))exit(0);

11131 sambar_DoS
if(! get_port_state(port)) exit(0);
if(http_is_dead(port:port))exit(0);

I don't pretend to be a nasl expert, but they appear to be doing the checks
correctly. Your name is on the last one so, again, they seem correct. ;)

But like I said, suppose argosoft and ws4d are running in parallel. Both of
them check the port state, and both determine the web server is alive. While
each of them is performing their respective incantations, one of them, or
perhaps even some other script, crashes the server. Each of them in turn
finishes its own payload and checks if the port is dead. argosoft says dead.
ws4d says dead. Both of them report they crashed the web server. But they
can't both be right. (Well, they could, if the trick to crashing the server
was that you had to do both payloads in parallel, but that would be a new
vulnerability from the individual tests in these particular scripts)
You can see why I'm hesitant to call them false positives. I mean, they're
right, the service took a dive while they were running... The only question
is why.

So....
If the scripts aren't wrong...
And the functions above are assumed to work properly...
And there's not already a serialization process for Denial of service...

Then the answer would appear to be that the easy fix of changing something
in the script is not the answer, that it's the hard solution of making
nessus serialize Denial of Service in order to accurately report results.

I suppose it wouldn't really be that hard to do it the unoptimized way...
If the script is DoS script, it could do a spinlock mutex (either global
or keyed to the port number it's working on) waiting for exclusive rights
to crash that service.(heh heh Bill, they're waiting in line to crash you)

Unfortunately in order to really optimize things, the spinlock would
have to be done automagically in the interpreter without the plugin
counting against the maximum number of simultanous plugins running.
Otherwise, in the worst case of n plugins allowed, all n are after the
same port, and n-1 are frozen waiting for their turn.

Don

Although speaking of false positives, I do see the SQL hello or the SQL
sapphire a lot on "fully patched" servers. Anyone know much about these?