This pops up occasionally. This fixes a couple of anecdotal reports of missing
requires that cause the loader to fail, depending on the directory sort order.
It also fixes the problem as reported in #6460
Fix#6445
Problem:
When an HttpServer instance is trying to register a resource that
is already taken, it causes all HttpServers to terminate, which
is not a desired behavior.
Root Cause:
It appears the Msf::Exploit::Remote::TcpServer#stop_service method
is causing the problem. When the service is being detected as an
HttpServer, the #stop method used actually causes all servers to
stop, not just for a specific one. This stopping route was
introduced in 04772c8946, when Juan
noticed that the java_rmi_server exploit could not be run again
after the first time.
Solution:
Special case the stopping routine on the module's level, and not
universal.
def peer is a method that gets repeated a lot in modules, so we
should have it in the tcp mixin. This commit also clears a few
modules that use the HttpClient mixin with def peer.
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.
Most exploits don't check nil for generate_payload_exe, they just
assume they will always have a payload. If the method returns nil,
it ends up making debugging more difficult. Instead of checking nil
one by one, we just raise.
Platform can be seen from different sources:
1. From the opts argument. For example: When you are using
generate_payload_exe, and you want to set a specific platform.
This is the most explicit. So we check first.
2. From the metadata of a payload module. Normally, a payload module
should include the platform information, with the exception of
some generic payloads. For example: generic/shell_reverse_tcp.
This is the most trusted source.
3. From the exploit module's target.
4. From the exploit module's metadata.
Architecture shares the same load order.
We haven't been able to get the XML data that would cause the error, all we have is a backtrace. So "verification" is purely code reading. Thanks @wchen-r7
Fixes#6085
Merge remote-tracking branch 'origin/pr/6259'
Brent Cook