We now use ints, and hopefully this means we don't have as much obvious
stuff in the binaries!
```
$ # Before:
$ strings metsrv.x86.dll | grep core_ | wc -l
46
$ # After:
$ strings metsrv.x86.dll | grep core_ | wc -l
0
```
Big win, and it's even bigger for the likes of stdapi.
Had to fix a bunch of other stuff along the way, including a subtle
issue with the Powershell Meterp bindings.
The 'common' library has been removed. The only project that actually
used it was metsrv, so the code that metsrv required from common is now
directly compiled in as part of that project.
The common folder now contains files that are importanta cross all of
the projects, with a primary focus on the new "API" style function. What
this means is that MetSrv has an API that it exposes through a function
pointer that is passed to the extension when it's initialised. This
pointer references a structure with all the API functions wired in. This
means that:
* Extensions don't need to know anything about metsrv at compile time.
* The delay loading code can be removed, which was one of the last
instances of "metsrv.dll" as a string.
* Metsrv.dll no longer exports any functions.
More to come.
This moves the existing network interface enumeration code over to the
group TLV packet approach which allows for arbitrary numbers of entities
to be added on the fly instead of fixed numbers.
This allows the client side to determine whether to fall back and gives
the user a better chance of seeing that it isn't listening where they
told it to.
Lots of transported related things were in the core library which didn't make any sense given that the only thing that needed it was metsrv. This moves the functionality out into metsrv, reformats stuff and gets rid of some dead code.
TODO: Make this work with POSIX.
During the call which establishes a TCP client channel, the call
to `connect` can sometimes fail if the settings that are used are
incorrect (such as an invalid port number). When this call fails
the result was being set to `GetLastError()`, which isn't correct.
On Windows it should be `WSAGetLastError()` and on POSIX the `errno`
value should be used instead. This wasnt causing issues on Windows
but on POSIX it was causing problems because the `GetLastError()`
call was returning zero, which was returned to the function that
invokes `create_tcp_client_channel()`.
Given that `ERROR_SUCCESS` == 0, the caller believed the function
had completed successfully and hence relied on context being set up
correctly. This was resulting crashes because this obviously wasn't
the case.
I also added a code chance which makes meterpreter attempt to bind
to `0.0.0.0` if binding to the specified address fails.
POSIX was out of whack with Windows as a result of the changes made
around channels. The schedular in posix was very different, and this
commit brings it into line.
Other than the obvious issues, a non-obvious issue with the changes
was that the channel was being freed up on close prior to the thread
terminating. This doesn't appear to be an issue on Windows, but was
causing crashes on close in POSIX.
The changes go quite deep. This changeset requires a lot of testing.
The goals of this work are:
* To fix issue where backgrounding and re-interacting with channels wasn't
working.
* To fix issue where closing of meterpreter was not closing off background
prcoesses (such as cmd.exe).
The two things preventing this stuff from working were:
* When interactive channels are backgrounded their handles were destroyed
along with the context that wraps them up. Making them interactive again
had no impact because the handle and context were invalid. If anything,
this made meterpreter unstable. Sometimes the session would die when
attempting to interact with the channel again.
* When closing channels, there was no way of terminating the process that
sat behind the scenes because no reference to the process was retained.
Channels would close and handles would close, but no process termination
was done.
To fix these problems:
* The interactive thread no longer terminates when backgrounded. Instead
its put in a suspended state where it's waiting a signal from a resume
handle that's associated with the channel's context. This means that the
destruction of the context doesn't happen at all until the termination
of the channel, which is exactly when it should happen anyway.
* Process handles are stored alongside the input/output handles so that
when the time comes, the process can be terminated if required. This
means that when the channels are closed, the code has a reference to the
associated process which can be terminated. This is only done for
interactive processes, non-interactive processes do not have this
problem because meterpreter doesn't have to keep track of them.
Thanks to @jvazquez-r7 doing some investigation we have a better solution
to this crash. This commit implements this fix and removes the need to
check the status of the memory that's being read.
Exploitation of the System process on Windows XP SP0 resulted in crashes
when metepreter was enumerating network interfaces. It appears that the
System process isn't able to read from the address that contains prefixes
(stored in pPrefix in interfaces.c). In other cases, such as exploitation
of svchost.exe or via an msfpayload-generated exe, there was no such
crash. This is not an issue on later versions of Windows.
This crash happens in the current "production" version of Meterpreter that
was deployed with MSF v4.7.
The MS08-067 exploit targets the System process, and hence crashes.
The MS03-26 exploit targets svchost, and hence does not crash.
Checking the protection of the memory in each of those cases showed that
the MEM_COMMIT was set when not the System process, and was MEM_RESERVED
when it was. Sample runs can be seen here: http://pastebin.com/2WHqJ90A
This commit is an attempt to avoid this crash down the track, and it just
does a simple check to see if querying the area of memory for the current
process shows a state of MEM_COMMIT. If so, it carries on as per normal,
if not it uses the other legacy code path to traverse the network
interfaces.
With this "fix" in place I have not seen a crash at all on Windows XP,
Windows 7, Windows 8 and Windows 2012.
