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.
Minor tweaks after the PR from @kernelsmith
Remaining items:
1. Handle empty session IDs correctly, for example 'sessions -d' or 'sessions -k'
2. Find a method of explaining the range options in the help text
3. Retest all changed code areas
4. Edit PR Summary to reflect changes to the scope
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.
- Added check for un-detach-able sessions
- Added back the check for session.interactive? when detaching sessions
- Collapse build_jobs_array and build_sessions_array to build_range_array
- Added check for empty or invalid parameters to detach and kill [session | job]
- Reworked session id sanity check around line 1660
- RuboCop/Style guide change: Array.new -> []
- Misc RuboCop/Style guide spacing changes
* Add RPORT as a regular option, define rport
* Add CPORT as an advanced option, define cport
* Change CHOST to an advanced option
* Use a more sane THREADS value since hosts are scanned in batches
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.
This makes it somewhat easier to use FTP server exploit modules in
somewhat more restrictive networks, where you might only have a few
inbound ports to choose from.
MSP-11145
**NOTE: Failing specs**
Add a tool for reading `log/untested-payload.log` and
`framework.payloads` to determine `context`s to add
`spec/modules/payloads_spec.rb` to test the untested payloads.
MSP-11145
Extract the spec task action which errored out if
`log/untested-payloads.log` exists to
`Metasploit::Framework::Spec::UntestedPayloads.define_task`.
This commit contains three fixes as requested on PR
#4003. Those include:
+ Removing extraneous puts statement
+ Checking for valid response
+ SSL support.
Instead of the eventual target where our proxy chain will connect. In
the usual case (no Proxies set), this will be the same output as before.
When proxies are given, the user will see that the first proxy
connection is actually what failed.
MSP-11126
Fully-qualify `Msf::MODULE_TYPES`, `Msf::MODULE_ANY`,
Msf::MODULE_ENCODER`, `Msf::MODULE_EXPLOIT`, `Msf::MODULE_NOP`,
`Msf::MODULE_AUX`, `Msf::MODULE_PAYLOAD`, `Msf::MODULE_POST` so that
their usage isn't dependent on nested lexical scoping.
MSP-11152
When `Msf::DBManager::Import::MetasploitFramework` is included in
`Msf::DBManager::Import`, it's child namespace of
`Msf::DBManager::Import::MetasploitFramework::Zip becomes resolvable as
`Zip` in `Msf::DBManager::Import` methods, so need to use `::Zip` to
cause `Zip` to be resolved from rubyzip gem.
MSP-11152
Constant was unqualified in some of the reorganized Msf::DBManager code
because that code was take advantage of the old nested lexical scope
that included `Msf`.
MSP-11126
`Msf::Module::Author` was already aliased to `Msf::Author`. This just
moved `Msf::Module::Author` to that alias to free up
`Msf::Module::Author` so it can be used for a concern for
`Msf::Module`'s author methods.
Luke Imhoff
jvazquez-r7
sinn3r
Tom Sellers
Joshua Smith
Tod Beardsley
Jon Hart
agix
HD Moore
William Vu
James Lee
Joe Vennix
scriptjunkie
nstarke
Spencer McIntyre
Tim Wright
Trevor Rosen