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.
The merge_check_key method (found in Msf::Module::ModuleInfo)) uses
respond_to? to check is our object includes a merge_info_description
method before merging descriptions. The respond_to? method in 2.1.4
by default no longer checks private and protected methods, and this
is breaking our merge_check_key method.
Fix#4163
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.
This will fix issue #4119. A bug in the find_first method in rex
SMB.
When the SMB client requests a TRANS2_FIND_FIRST2 for retriving
information about what items a directory has, the server returns
a response that contains an SID - a search identifier for the
transaction. If the SMB client wants more data, it must send a
TRANS2_FIND_NEXT2 request with the same SID. And then the server
will continue sending more until it runs out.
The root cause of this bug is that after the TRANS2_FIND_FIRST2
request is sent, our SMB's find_first method forgets the SID at
the end of the loop (out of scope).
There has been Meterpreter work done as well to support this. But this
commit allows for a new 'getsid' command which tells you the sid of the
current process/thread. This can be used for things like determining
whether the current process is running as system. It could also be used
for golden ticket creation, among other things.
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.
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.
Luke Imhoff
Jon Hart
Trevor Rosen
sinn3r
William Vu
Tod Beardsley
HD Moore
jvazquez-r7
Joshua Smith
OJ
Julio Auto
Tom Sellers
agix
James Lee
Joe Vennix