Renaud Deraison wrote:
>
> On Tue, Jun 25, 2002 at 04:32:15PM -0400, Thomas Reinke wrote:
> > I'd like to propose for consideration that when safe_checks is
> > disabled (ie. the go for the throat real test), that the nasl
> > script STILL report the safe_check results _independently_,
> > labelling it as such.
>
> No, that would make no sense. Imagine the following reports :
>
> "You are running version x.y.z of SomeProduct. Versions < x.y.z+2 are
> vulnerable to a remote overflow.
>
> The testing of the overflow failed"
Actually, while I wouldn't word it that way, that IS what I would
expect to see. Consider an alternate wording:
"You are running version x.y.z of SomeProduct. Versions < x.y.z+2
are vulnerable to a remote overflow. While we couldn't confirm
the vulnerabilitiy exists, the banner suggests that it does."
This is, btw, already done in Nessus - consider the check for the
DELETE method on a web server:
"It seems that the DELETE method is enabled on your web server
Although we could not exploit this, you'd better disable it."
I don't really this as any different. (You could argue that the
latter shouldn't hae been done. In which case I can't come up
with a counter-argument ;-))
>
> And :
>
> "It was possible to make the remote SomeProduct crash. Upgrade to
> version x.y.z-2" (whereas you're running version x.y.z already).
>
> Safe checks and "regular checks" are two different testing
> methodologies. Combining them will just add noise and confusion.
>
> > Case in point: the recent Apache chunked encoding vulnerability.
> > We all know that versions < 1.3.26 are vulnerable, yet it has
> > been reported on this list that some versions are not being
> > flagged as vulnerable.
>
> That's true. Some plugins will fail. In this case, Apache-on-Solaris
> refuses to die (investigation is being done). But in other cases, a bad
> regexp may not catch a vulnerable version to some product. These are
> called bugs, they happen and they usually get fixed.
The problem I see with the above is that when there is a bug
suggested by a banner, and you don't report that you know this,
you immediately set yourself up for failure by ignoring that
and 100% rely on the non-safecheck test method.
Will it add noise? That is subjective. Removal of noise at the
expense of not providing as complete a report as possible is IMHO
not the way to go. I'd rather filter some noise than to have to
wonder if the scanner is working properly. Also, consider that
if someone mangles a banner, they'll know it and the "noise" is
easily discounted. That's MUCH less problematical than being
forced to run a scanner twice against every IP to get results.
Also, keep in mind that you are unlikely to ever be able to test
a script against all the processor/Apache combinations out there
(I'd estimate several hundred). Every time you have large
number like that, you're bound to run into scenarios you didn't
account for. In that situation, a tester should at least be
given the banner information to work with (without re-running
the test suite).
Thomas
