* Updated `thread_create` so that it has 3 parameters, and removed
`thread_create3`.
* Updated all calls to `thread_create` and added the extra parameter of
`NULL`.
* Fixed comment typo.
* Removed assignment where value is not used.
* Checked for `NULL` prior to setting the result.
* Undefined `DEBUGTRACE`.
This work contains a bunch of changes around command dispatching. The
goals for this bit of work were to:
* Provide the ability for commands to be executed on the same thread as
the server rather than always creating new threads and executing them on
those threads.
* Have the means for _special_ commands, such as `exit` and `migrate` to
shut down the server cleanly without having to rely on signalling across
threads or by doing brutal thread termination via shared global handles.
This should not only fix the dirty shutdown problem on Windows which
leaves tasks dangling (or based on the prior attempt at fixing, crashing
stuff as well), it should also help clean up the shutdown process in
POSIX.
These changes hit a very important part of Meterpreter and so should be
reviewed with intense scrutnity. I expect this PR to garner a log of
critique and most likely a number of changes before being included in the
main line.
The `PacketDispatcher` was modified to include a new function pointer
called an `inline_handler`. This new member indicates that there's a
handler which should be invoked inline. While this sits alongside the
existing `handler`, they are actually mutually exclusive. If an
`inline_handler` is specified then the `handler` is ignored and it is
assumed that the command is intended to be handled inline. The signature
of the inline handler is different to the standard handler, and this is
why a new function pointer was added rather than a simple flag. Addition of
this parameter meant that the basic command structure changed, and that
obviously affects all of the extensions and their respective commands.
This changeset therefore updates each of those command declarations so
that they use the new macros that hide this detail.
Other things to be mindful of:
* This version of the code reads the command's `method` prior to invoking
any other function, and after that the command itself is passed around to
the threaded or non-threaded routes for invocation. An extra thread
parameter was included as as result, and an overload for the
`thread_create` function was added which supported this new parameter.
This was named `thread_create3` because
`thread_create_with_another_paramter` sounded a bit crap.
* The migration code, which originally had a `thread_kill` and an event
wait once the new meterpreter session had been created, has been modified
to not do any waiting at all. Instead it finishes execution as fast as
possible and returns control to the server which should respond by
shutting down in a clean way.
* Originally the code always attempted to call a command handler in the
base command list and then, if found, would also call an "overload" in
the extension commands list. From the investigation that I did, it
appears that the overloaded methods did nothing in the base (they'd
early out during invocation). As a result, the new way of doing things
acts like a 'true' overload in that the extension commands are searched
first, and if one is found this is the command that is executed. Any
base commands with the same method name will not get executed. In the
case where there is no extension command found, the base command list is
then queried. If a command is found that command is instead invoked.
* The POSIX version still compiles cleanly, but I've never been able to
build a version that runs on my machines. I'm not sure if there's a
trick to getting POSIX builds to run, and if there is I don't know it.
Whoever scrutinises this build should make sure that the POSIX version
that they build can still run and (hopefully) exit cleanly.
I've added lots of documentation, but there's always room for improvement.
Hopefully this will fix the `*_tcp` side of Redmine 8438.
Bring on the feedback!
Big job, this documentation lark. Also modified the prototype the
packet_is_tlv_null_terminated function, which used to take a Packet
instance as well as the TLV, but never used the packet in its
implementation.
The main issue with things being broken was because the calling
convention was not defaulting to "stdapi" and hence the call would
fail. Adding the default fixed it.
While fixing this, I brought the mulit-call functionality up to speed
with the error message functionality, so the calls all return the
properly formatted error message.
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.
This code was lost in the transition when the meterpreter source was
removed from the metasploit-framework source. I'm pulling this in by
request of @dmaloney-r7 who originally requested this code be inculded
as part of https://github.com/rapid7/metasploit-framework/pull/740
I added an extra bit of code to free up memory that is allocated by the
call to FormatMessage and forced the ASCII-version (FormatMessageA) of
the call.
* make_pair() changed in C++11 so this change fixes the code so that the
compiler doesn't complain any more.
* Compiler was also complaining about redefinition of U_CHAR. Undefining
before redefining resolves the issue.
Initial commit of in-mem-exe.c modifications for Windows x64.
Initial boolean wrapper checks to see if the image supplied is a
valid 64bit PE and calls a 64bit injection function. wow64 not yet
implemented.
64bit execution is a bit tricky since we can't get the entrypoint
of the existing thread from ThreadContext.Eax and we need to make
sure that our images are properly aligned. The 64 bit mapper is
based on MemExec64 source code by Steve10120 [at] icode.org.
TODO:
Write wow64 based injector. Write conditional to check that
source and destination images are the same architecture and call
the arch appropriate injection method.
Write "Heaven's Gate" based injector for running x86 process in
x64 space.
