Connecting to a Non-Existent Pipe in Meterpreter Will Cause the Session To Crash - Needs Better RPC handling

[gwillcox-r7]

Currently Meterpreter does not check whether or not a Windows pipe exists prior to connecting to it. Whilst testing #625 I determined that trying to exist to the nonexistent pipe \pipe\efsrpc, a pipe that doesn't start unless the EFS service has started, will crash the Meterpreter session. Similarly any RPC connection errors such as the RPC server not being available or the pipe not being available will cause the Meterpreter session to crash.

Overall I question why we haven't added better error handling for something like this. RPC is a fiddly beast and its easy to get something wrong, yet we seem to be acting as though this isn't the case and blindly trusting things, which looks like an error to me, particularly if its crashing sessions. Given exceptions are thrown though I'm wondering if we need to have better exception handlers as unhandled exceptions seem to crash the session given the stack traces we have been looking at thus far.

Anyway just wanted to post this here as its highly likely we will run into this again in other work as well.

[smcintyre-r7]

Can you provide steps for reproducing the error you're running into? Are you for example disabling the EFS service then running getsystem or is the service not running by default in certain cases?

[gwillcox-r7]

@smcintyre-r7 Sure. Install a Windows 11 22H2 distro. Create an account and then type type \\.\pipe\efsrpc. See that the pipe isn't available. Apply the updates from #625 and rebuild the DLL. Use that DLL and then try technique 6. See that it crashes on a RPC server not available issue in WinDBG Preview. Start the EFS service with net start EFS. Now gain another session and try technique 6 again. See that it works.

This is also detailed in more detail on the comments on #625

[smcintyre-r7]

Since #625 is switching to use \\.\pipe\efsrpc, it should be checked to see if it's available before proceeding which means that PR should be updated before it's landed lest it introduce a bug. That's reasonable.

This issue however makes it sound like a lack of checking for pipe availability is currently a wide spread issue in the current code base. If that's the case, can you provide steps to reproduce that error other than related to the missing check that should be added in #625.