meterpreter,still not reliable ?

[mmiller at hick.org (mmiller at hick.org)]

On Wed, May 18, 2005 at 02:16:00AM -0700, Hamid . K wrote:
> Hi ,
>
> I went to see how it really works  , in a real-world
> use . not sure if it was my problem or framework when
> "win32_bind_meterpreter" as selected payload ,
> but about 6 of 10 attempts fail on this payload .
> note that I was using WINS module . how ever WINS
> module
> included in MSF is not perfect but it works on normal
> cases . 
> any special comment while using "meterpreter" as
> payload ?

Hard to say why it would not load 100% of the time.  The staging
payloads are suspectable to latency and if it happens that only a
portion of the stage is read in then the payload will fail.  This is
generally uncommon but could be more common on slower network links.
The DLL injection stage is rather large (~2800bytes if memory serves me
correctly), so the transmission of the stage is bound to be split into
at least two TCP packets (with TCP MSS being 1460 normally).  You can
try to confirm that this may or may not be the case by attaching to the
process that is being exploited and seeing if it is crashing in an
unexpected manner.  Does this issue only occur when exploiting WINS, or
does it also occur when exploiting other services?

> will we see any linux ver. of this payload ? :>

DLL injection is a little more complicated to do on Linux in a portable
and robust manner.  The general consensus is that the most reliable way
to accomplish this is to do client-side relocation processing with a
base address that is provided by a stub payload that executes on the
target machine (by having it mmap a region large enough to hold the
DLL).  After that, the relocated in-memory contents of the library can
be sent across and copied to the region after which point the rtld base
must be located so that imports can be resolved properly by the library
when they are used (or the payload needs to do manual import processing
which is going to incur a most likely substantial size increase).  The
other problem you run into with DLL injection on Linux is glibc symbol
versioning which makes it more challenging to portablely load shared
libraries on various distributions of Linux that have different versions
of glibc.  Optyx identified that one way to work around this issue is to
implement a custom rtld stub that is responsible for resolving symbols
in a version independent manner.  At any rate, it should be possible,
it's just that all of us have day jobs and we've been working on other
things lately in our freetime (like msf3), so we just haven't gotten
around to implementing it :)