We add finalizers to an assortment of Meterpreter-managed objects in order to
clean things up in the event that a post module crashes and does not clean
things up. However, this also means that even a properly-written post module
can lead to an object getting double-closed on the Meterpreter session when the
garbage collector kicks in. This can lead to quite non-deterministic behavior
and crashes.
This change modifies the instance close methods to unregister the finalizer on
close, ensuring we cannot do a double-close automatically if one is requested
explicitly first. As an additional measure, we check an instance variable to
see if we called close directly twice as well. This is not sufficient in
itself, since we do not have a reference to 'self' in the finalizer proc to
check the close state.
This also removes a couple of references to 'self' in the finalizer proc
itself, which may cure some memory leaks as well due to circular references.
This patches changes two things:
1. If a module has a custom Content-Length, it will respect that
instead of forcing its own.
2. If a request does not have anything in the body, the
Content-Length header will not be set.
Fix#6609Fix#6587
Exploit::Remote::HttpServer and every descendant utilizes the
print_prefix method which checks whether the module which mixes in
these modules is aggressive. This is done in a proc context most
of the time since its a callback on the underlying Rex HTTP server.
When modules do not define :aggressive? the resulting exceptions
are quietly swallowed, and requestors get an empty response as the
client object dies off.
Add check for response to :aggressive? in :print_prefix to address
this issue.