This deletes some old code that apparently has been broken and somewhat unused for many years.
The 'derived_implementor?' method for modules relies on the debug output from Ruby in order to tell of a class implements a method, but the regex it used didn't work properly with any modern Ruby version until 2.5.x. This caused a random sleep to get inserted into certain payload staging operations, which actively breaks staging in certain scenarios (I'm not trying to address that here).
This also removes some ancient module feature detection code, which also is entirely unused today.
Any exploit that includes an aggressive stance is aggressive, regardless
of whether or not it has passive components.
This fix should prevent known-aggressive exploits from backgrounding.
Things like browser exploits don't have remote host options
which is what auto targeting relies on, so it does not make sense
to include the auto-targeting in these exploits
7837
the target selection actually adjust the datastore
as if a user selected the target, this prevents
a mismatch between the target and the target index
MS-2325
if the module authour added an automatic target
we skip our routine, to let the module's own automatic targeting
take over as it likely be better
MS-2325
This streamlines the check for whether the currently-selected payload is
compatible on assignment. Rather than building the entire list of
compatible payloads, and seeing if what the user typed is in it (and
making multiple giant lists on the way), we simply check the module the
user typed directly.
reimplement HD's work on a session interrupt handler
so that if an exploit fails the handler does not continue
waiting for a session that will never come
MS-385
Fix#6371
When a browser fails to bind (probably due to an invalid port or
server IP), the module actually fails to report this exception from
exception, the method calls exploit.handle_exception(e). But since
handle_exception is not a valid method for that object, it is unable
to do so, and as a result the module fails to properly terminate
the module, or show any error on the console. For the user, this will
make it look like the module has started, the payload listener is up,
but there is no exploit job.
Rex::BindFailed actually isn't the only error that could be raised
by #job_run_proc. As far as I can tell registering the same resource
again could, too. With this patch, the user should be able to see this
error too.
Since the exploit object does not have access to the methods in
Msf::Simple::Exploit, plus there is no other code using
handle_exception and setup_fail_detail_from_exception, I decided
to move these to lib/msf/core/exploit.rb so they are actually
callable.