[Nikto-discuss] nikto using 1.5Gb memory
Andres Riancho
andres.riancho at gmail.com
Wed Dec 16 12:39:03 UTC 2009
Sullo,
Please read inline,
On Tue, Dec 15, 2009 at 12:19 PM, Sullo <csullo at gmail.com> wrote:
> Thanks for posting Tim, appreciate it.
>
> It's the hated/loved -mutate options. Ok, so this is both bug and not
> bug. Tests are indeed queued in memory when the scan is set up, since
> we don't have a real database to use for temporary storage. During a
> "normal" scan, this isn't much of a problem because the memory
> utilization is fairly low.
>
> However, when you start using the mutation techniques, the number of
> queued requests gets seriously large--hence the memory problems.
>
> I can think of a few ways to once and for all solve this mutate memory issue:
> - get rid of mutate
Thats not an option, people use it =)
> - use temporary storage
> - use a 'real' database (I know Dave talked about this a while back)
As you say in another email, this means adding a dependency, not
always an option.
> - make multiple iterations through the scan database (store smaller
> portions in memory)
I think that this is one of the best.
> That's all I can think of, from least to most "interesting" ways to
> solve it. The multiple iterations thing probably would require some
> hacks to the core which doesn't sound too good, though...
>
> Anyone?
I think that another way to solve it is the following:
- Create a Queue object with a size limit. The queue should block when
somebody tries to add a new item and the size limit is hit. The Queue
object should have ~1000 in size.
- Create a thread that iterates through the mutate tests, and adds the
tests to the Queue. At any given time, you'll have at most 1000 tests
in memory, solving the memory usage issue.
- Create another thread, that will read from the Queue and send the
requests to the web server. If this thread reads from the Queue and
there are no objects, then the scan is over. The only problem that
could be found is that there are still tests to perform, but for some
reason they were not added to the Queue before the test thread reads
from it, but this can be easily solved by doing some double-check.
This is one of the best ways of solving this issue (no extra
dependencies, no disk usage, no ad-hoc database), which I found some
time ago while developing w3af.
Regards,
> -Sullo
>
> On Tue, Dec 15, 2009 at 9:59 AM, Tim Waters <tim.waters at lbvd.nl> wrote:
>> Hi list,
>>
>> Today my Nikto hung up on by using 1.5 Gb of memory. I had a tweet about
>> it and Chris asked me to put it on the list.
>> So here it is :)
>>
>> This is what I did.
>> 1. I had not used nikto in a while, so decided to update it first with
>> nikto --update like this:
>>
>> ./nikto.pl -update
>> + Retrieving 'db_outdated'
>> + www.cirt.net message: Please submit your bugs!!
>>
>> 2. I ran a scan with a few options like this:
>> ./nikto.pl -Cgidirs all -host <IP> -mutate
>> ../../../../Desktop/scan/03.nikto-<ip-address>.txt
>> - Nikto v2.03/2.04
>> ---------------------------------------------------------------------------
>> + Target IP: <IP>
>> + Target Hostname: <HOST>
>> + Target Port: 80
>> + Using Mutation: Test all files with all root directories
>> + Using Mutation: Guess for password file names
>> + Using Mutation: Enumerate user names via Apache (/~user type requests)
>> + Using Mutation: Enumerate user names via cgiwrap
>> (/cgi-bin/cgiwrap/~user type requests)
>> + Start Time: 2009-12-16 10:03:17
>> ---------------------------------------------------------------------------
>> + Server: Apache
>> ^Cbash: [8182: 1] tcsetattr: Interrupted system call
>>
>> In the last line you can see I had to interrupt it because it slowed my
>> system down to much.
>>
>> Other scans with less options ( setting -Cgidirs to none, setting
>> -mutate to 2 or 3, or lossing -mutate at all ) did not end up with nikto
>> using as much memory.
>>
>> More info:
>>
>> Nikto Versions
>> ---------------------------------------------------------------------------
>> File Version Last Mod
>> ----------------------------- -------- ----------
>> Nikto main 2.03
>> LibWhisker 2.4
>> db_404_strings 2.000
>> db_favicon 2.003
>> db_outdated 2.008
>> db_realms 2.000
>> db_server_msgs 2.002
>> db_tests 2.004 #LASTMOD:Mon Jan 26
>> 11:34:05 2009
>> db_variables 2.000
>> nikto_apache_expect_xss.plugin 2.00
>> nikto_apacheusers.plugin 2.02
>> nikto_cgi.plugin 2.02
>> nikto_core.plugin 2.04
>> nikto_favicon.plugin 2.04
>> nikto_headers.plugin 2.03
>> nikto_httpoptions.plugin 2.03
>> nikto_msgs.plugin 2.02
>> nikto_mutate.plugin 2.03
>> nikto_outdated.plugin 2.04
>> nikto_passfiles.plugin 2.00
>> nikto_plugin_order.txt 2.00
>> nikto_put_del_test.plugin 2.01
>> nikto_reports.plugin 2.02
>> nikto_robots.plugin 2.01
>> nikto_single.plugin 2.00
>> nikto_user_enum_apache.plugin 2.01
>> nikto_user_enum_cgiwrap.plugin 2.02
>>
>> Regards,
>>
>> Tim
>> _______________________________________________
>> Nikto-discuss mailing list
>> Nikto-discuss at attrition.org
>> https://attrition.org/mailman/listinfo/nikto-discuss
>>
>
>
>
> --
>
> http://www.cirt.net | http://www.osvdb.org/
> _______________________________________________
> Nikto-discuss mailing list
> Nikto-discuss at attrition.org
> https://attrition.org/mailman/listinfo/nikto-discuss
>
--
Andrés Riancho
Founder, Bonsai - Information Security
http://www.bonsai-sec.com/
http://w3af.sf.net/
More information about the Nikto-discuss
mailing list