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.
MSP-11130
Fail `rake spec` if
`Metasploit::Framework::Spec::Constants::Each.configure!`'s
`before(:each)` does not clean all leaked constants and if should be
removed so that it does not interefore with future specs.
MSP-11130
`Metasploit::Framework::Spec::Constants::Each.configure!` will set up an
`after(:each)` callback that will fail the example if there are leaked
constants. Leaked constants are cleaned up to prevent misattribution.
MSP-11130
`Metasploit::Framework::Spec::Constants::Suite` extracts out
`LOG_PATHNAME`, `configure!`, and `define_task` as those piece are
specific to handling constant leaks for the entire suite. This is in
preparation for `Metasploit::Framework::Spec::Constants::Each`.
MSP-11130
Constants from library Modules or Classes should not be reported as
leaked since they have been required and should be persistent between
spec runs.
MSP-11130
Extract method to convert child constant names to module full names so
it can be reused 'Metasploit::Framework::Spec::Constants tracker' shared
context.
MSP-11130
Instead of printing the leaked constants to stderr, log them to
`log/leaked-constants.log`. In task action for spec, read
`log/leaked-constants.log`. If it exists, print each leaked constants
(and it appropriate it's module full name) and then exit with 1. If the
file does not exist, do nothing.
Tod Beardsley
Fernando Arias
Matt Buck
Trevor Rosen
Samuel Huckins
Luke Imhoff
sinn3r
HD Moore