The goal is to avoid pointer truncation where possible so this commit
changes parameter types to qword where it makes the most sense. This
includes all handles (event, process, thread, registry), addresses
and generic parameters.
Crashes were occuring when the underlying channel had no more output
because the value of the `bytesRead` variable was not set to zero.
Consumers of the function assumed that bytesRead was value if non-zero.
POSIX would also hang when unsupported commands are executed, this
commit changes this so that a response is returned when the command
isn't supported.
Does as it says on the tin. Various tweaks made to source and to project
files to make the builds come out with ZERO warnings.
Let's keep it clean from here!
This changeset brings windows into line with the last set of POSIX
changes. With this changeset we are now in a position where both POSIX and
Windows are able to create and open interactive channels, put them in the
background, and terminate them without crashing, hanging or leaving
processes running behind the scenes.
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.
Fixes client.sys.process.execute for posix, which previously (since
2010!) would always return nil, or a single byte. This makes sense
considering the value of bytesRead would always be either 0 or 1 because
it was being assigned the result of the comparison instead of the return
value of read().
[Fixes#681]
Fixes some TypeError exceptions when attempting most operations on
spawned processes, e.g.:
p = client.sys.process.execute("/bin/sh", nil, "Channelized"=>true)
p.close
# raises TypeError: can't convert nil into Integer
[FIXRM #7005]
commit df6eef12147a294d7f198d057c27e87ed4ffbeb3
Author: MM <gaspmat@gmail.com>
Date: Tue Mar 20 18:01:50 2012 +0100
ps support for linux meterpreter
[Closes#250]
In posix, a command like "echo 'foo bar'" would previously get parsed
out into arguments for execve like [ "echo", "'foo", "bar'" ] which
obviously isn't what you want. After this commit, it sticks the whole
thing in an arg to sh so the execve call ends up looking like
execve("/bin/sh", ["sh", "-c", "echo 'foo bar'"], [/* 26 vars */]) = 0
This is still a little less than ideal because shell escapes become a
problem; fortunately, that's easy to deal with on the client side as
long as module developers take it into account.
