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.
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'
Running a local exploit like a post is not currently supported,
we should at least raise a warning or something, and not just
let it backtrace and confuse the user.
Brent Cook