DB_ALL_CREDS worked but DB_ALL_USER and DB_ALL_PASS
did not. working on fixing that.
This commit also does some nice DRY work in the auth_brute mixin
MSP-11986
bruteforce_speed isn't always required, because the speed checker
already handles nil (and presumes the user wants the fastest possible).
See also MSP-11842
This implements just for telnet, but assuming this strategy is kosher,
it's not too painful to add for the rest of the LoginScanner using the
old defaults used by `AuthBrute`.
See #3904, @dmaloney-r7 or @jlee-r7
MSP-11671
Add command line option --defer-module-loads to msfconsole. It will
stop `Msf::Ui::Console::Driver` from calling
`framework.modules.init_module_paths` AND
`framework.modules.refresh_cache_from_database`. This flag is only
meant to speed up msfconsole boot when modules do not need to accessed,
such as during cucumber testing of command help or command line options.
MSP-11147
Sometime travis-ci is showing leaked threads even when
'Msf::Framework#threads cleaner' is being used, so I'm adding the
`Thread#status` to the data printed about the Thread to see if the
sometimes leaked threads have an odd status. There's still a chance
that there will be a race-condition between when I call Thread.list and
I ask for each Thread's status that the VM could finish aborting a
Thread so that status I print isn't the same as the one that caused the
Thread to be returned in Thread.list.
MSP-11605
`Rex::ThreadFactory.provider` needs to be set in
`Msf::Framework#initialize`, but setting it directly to
`Msf::Framework#threads` eliminates the laziness of
`Msf::Framework#threads`. In order keep `framework.threads` lazy,
`framework` is wrapped in a
`Metasploit::Framework::ThreadFactoryProvider`, which responds to
`spawn`, which is needed by `Rex::ThreadFactory`, by calling
`framework.threads.spawn`, which lazily initialized `framework.threads`
when the first thread needs to be spawned.
MSP-11147
When using Rubymine's debugger, the tests would run and say there were
no tests and no break points would be hit. It was determined that this
was due the Rubymine's debugger injecting itself into RUBYOPTS and only
working if it's first in RUBYOPT, which means that
'metasploit:framework:spec:threads:suite' must inject '-Ilib
-rmetasploit/framework/spec/threads/logger' at the end of RUBOPT instead
of the beginning.
This change adds two new Rex exceptions and changes the local comm to raise the right one depending on the circumstances. The problem with the existing model is
that failed binds and failed connections both raised the same exception. This change is backwards compatible with modules that rescue Rex::AddressInUse in additi
on to Rex::ConnectionError. There were two corner cases that rescued Rex::AddressInUse specifically:
1. The 'r'-services mixin and modules caught the old exception when handling bind errors. These have been updated to use BindFailed
2. The meterpreter client had a catch for the old exception when the socket reports a bad destination (usually a network connection dropped). This has been updat
ed to use InvalidDestination as that was the intention prior to this change.
Since AddressInUse was part of ConnectionError, modules and mixins which caught both in the same rescue have been updated to just catch ConnectionError.
Have 'metasploit/framework/spec/threads/suite/logger' generate a UUID
for each Thread. This UUID is printed on the "BEGIN Thread.new caller"
line and is assigned as a thread-local variable,
'metasploit/framework/spec/threads/logger/uuid'. In `after(:suite)`,
the log can be parsed to map the caller back to each UUID and then only
the UUID of the still existing threads is used to look up the caller and
print their stacktraces. This means only leaked threads callers will be
printed.
MSP-11147
Even with leaked threads, there may be no log if the suite is run
without `rake spec`, such as when `rspec` is used directly to run a
subset of specs.
MSP-11147
Merge to get framework instance cleanup, which should clean up a lot of
thread leaks too.
Conflicts:
Rakefile
lib/metasploit/framework/spec.rb
spec/spec_helper.rb
MSP-11147
Detect thread leaks in a `before(:suite)` configured by
`Metasploit::Framework::Spec::Threads::Suite.configure!` and fail if any
leaks are found.
By putting the db group into the metasploit-framework-db.gemspec,
bundler no longer automatically required 'metasploit/credential' and
'metasploit_data_models' because gems, such as metasploit-framework-db,
are expected to explictly require their dependencies.
MSP-11130
Have a task, 'metasploit:framework:spec:constants:each:clean' run before
`rake spec` that removes the previous
`log/metasploit/framework/spec/constants/each.log` so that the user doesn't
have to manually remove the load when removing
`Metasploit::Framework::Spec::Constants::Each.configure!` from
`spec/spec_helper.rb`.
MSP-11130
Instead of writing `1` to the file and then printing a verbose message
in the spec task action, log the verbose message and just print the log
in the spec task action, so other tools can just look at the log when
not using `rake spec`.
NOTE: Failing specs due to unnecessary
`Metasploit::Framework::Spec::Constants::Each.configure!`
MSP-11130
When removing `Metasploit::Framework::Spec::Constants::Each.configure`
from spec/spec_helper.rb,
`Metasploit::Framework::Spec::Constants::Each.define_task` will see the
`log/remove-cleaner` from the last run unless it is manually removed.
MSP-11130
Some constants can be leaked before suite if module are loaded during
spec loading, such as if a framework instance in made in the context
body of a spec instead of in a before callback.
MSP-11130
Print to stderr the full description of the example when
`Metasploit::Framework::Spec::Constants.configure!`'s `before(:each)`
cleans constants as it may clean constants that are leaked from the
class level at parse time.
Jon Hart
Meatballs
David Maloney
Tod Beardsley
Fernando Arias
Matt Buck
Trevor Rosen
Samuel Huckins
Luke Imhoff
sinn3r
HD Moore