Steps to reproduce
The MCP plugin does not gracefully handle bind failures. If msfmcpd was already started with ./msfmcpd --mcp-transport http, then the mcp start command fails with an undefined method stop exception and can't be started even if ./msfmcpd is killed.
To reproduce
- Start
./msfmcpd --mcp-transport http and wait for it to be up and running
- Leave
msfmcpd running and start msfconsole
- Run
load mcp and start the server with mcp start
- See:
msf exploit(windows/smb/psexec) > mcp start
[*] Auto-started msgrpc - User: msf, Pass: x5vFuDUjvIv5
[!] Failed to unload auto-started msgrpc: undefined method `stop' for nil
[-] Failed to start MCP server: RPC authentication failed: Login Failed
- Stop
msfmcpd with Ctrl+C and wait for it to shutdown
- Run
mcp start again, see that it's still failing to start even though the ports are available
Were you following a specific guide/tutorial or reading documentation?
If yes link the guide/tutorial or documentation you were following here, otherwise you may omit this section.
Expected behavior
The output should clearly state which server couldn't start (MSGRPC or MCP) and why (the address was unavailable). It should also not say that the server was started and then throw an error because if the server fails on startup then it was never started.
If the MSGRPC server bind succeeds, the plugin should also handle instances where the MCP server then fails to start because that port is already in use.
In both cases, if the server doesn't start the plugin should be in a consistent state where the services can have their status checked and accurately reported as well as restarted.
Current behavior
If the msgrpc server can't start because the ports in use, you get a cryptic undefined method error after it's stated that the server started and then it correctly states that it can't authenticate. In this case though, the authentication failed because we couldn't start the server we could authenticate to, so it'd be more informative to tell the user that the MSGRPC server couldn't start rather than that we failed to authenticate to it.
Steps to reproduce
The MCP plugin does not gracefully handle bind failures. If
msfmcpdwas already started with./msfmcpd --mcp-transport http, then themcp startcommand fails with an undefined methodstopexception and can't be started even if./msfmcpdis killed.To reproduce
./msfmcpd --mcp-transport httpand wait for it to be up and runningmsfmcpdrunning and startmsfconsoleload mcpand start the server withmcp startmsfmcpdwith Ctrl+C and wait for it to shutdownmcp startagain, see that it's still failing to start even though the ports are availableWere you following a specific guide/tutorial or reading documentation?
If yes link the guide/tutorial or documentation you were following here, otherwise you may omit this section.
Expected behavior
The output should clearly state which server couldn't start (MSGRPC or MCP) and why (the address was unavailable). It should also not say that the server was started and then throw an error because if the server fails on startup then it was never started.
If the MSGRPC server bind succeeds, the plugin should also handle instances where the MCP server then fails to start because that port is already in use.
In both cases, if the server doesn't start the plugin should be in a consistent state where the services can have their status checked and accurately reported as well as restarted.
Current behavior
If the msgrpc server can't start because the ports in use, you get a cryptic
undefined methoderror after it's stated that the server started and then it correctly states that it can't authenticate. In this case though, the authentication failed because we couldn't start the server we could authenticate to, so it'd be more informative to tell the user that the MSGRPC server couldn't start rather than that we failed to authenticate to it.