Thus spake Renaud Deraison ([EMAIL PROTECTED]):
>       - Disable the optimizations. Maybe a dependencie was not
>         met, so the test is not run (double check this using
>         nessusd.messages)

This was (part of (see below)) the problem.  I enabled this option, and
the scan started working as advertised.  It has found several hosts that
are vulnerable to this bug.  Thanks very much.  I should have read the
nessusd.messages file.
 
>       - If that fails, try to enable the safe checks, and see if the
>         hosts in question come up as being vulnerable (in which case
>         it would mean the current code snippet is not good)

However, this may also be the case.  We've found several versions of
apache which we know are vulnerable (and have vulnerable version numbers
that are caught by the safe check), but are failing the more extensive
test.  So far, we've seen some hosts apache 1.3.19, 1.3.12, and 1.3.16
(all running solaris, but I'm not sure it's tied to the OS) fail the 
in-depth test.

Here's what apache saw:

  scanhost.mydomain - - [date] "GET /index.html HTTP/1.1" 200 8208 "-" "-"

That's it.  There was nothing in the error_log 

Someone here who knows a lot more about apache than I do thought that
the web servers might have been silently downgrading the session to HTTP
1.0 (thus making the chunking thing irrelevant) since the nasl script
wasn't supplying a User-Agent string.  We added it to the script and 
tested it, but that doesn't seem to be the issue.

If you need any more information, please don't hesitate to ask.

Thanks,

David

Reply via email to