Options without a default were not pulled into the `@options` hash and
therefore were not used to validate options on assignment.
I am not entirely sure how this fix works, since it would seem that
non-override options would not get pulled in if an option was first set
in the global datastore. However, a previous value does not get
overridden and new values are validated. Anything further is merely
speculation on my part.
In current nomenclature, Rex Sockets are objects created by calls
to Rex::Socket::<Transport>.create and Rex::Socket.create_...
When the LocalHost or Comm parameters are set to remotely routed
addresses (currently via Meterpreter sessions), Rex will create a
Channel which will abstract communications with the remote end of
the session. These channel based abstractions are called pivots,
and present in three separate flavors:
1 - TcpClientChannel, a fully abstracted, selectable Socket.
2 - TcpServerChannel, a virtual Channel which distributes client
channels.
3 - UdpChannel, a virtual Channel which provides common methods for
UDP socket operations, but is not a full (selectable) abstraction.
Unfortunately this differentiation results in inconsistent returns
from the aforementioned socket creation calls, as the call chain
creates parameters and supplies them to the create method on the
comm object referenced in the params. The comm object may be a
channel, and produce a virtual representation of a socket with
functional methods analogous to Sockets, but without a kernel FD.
This commit begins the work of ensuring that all calls for socket
creation return selectable Rex::Socket objects with semantics
familiar to Ruby developers who have not read into the details of
Rex::Socket and Rex::Post.
-----
Summary of changes:
Convert Rex::IO::StreamAbstraction to SocketAbstraction and use
the new mixin in StreamAbstraction and DatagramAbstraction. This
approach allows for common methods to reuse the abstraction data
flow, while initializing separate types of socket obects and an
optional monitor as needed.
In the Rex::Post::Meterpreter namespace, extract common methods
from Stream to a SocketAbstraction mixin, include that mixin in
Stream, and add Datagram with the dio_write handler override
exported from the current implementation of UdpChannel, also using
the mixin. This relies on the Rex::IO work above to implement the
proper type of socket abstraction to the Channel descendants.
In Rex::Post::Meterpreter::Extensions::Stdapi::Net, convert the
UdpChannel to inherit from the Rex::Post::Meterpreter::Datagram
class, implementing only the send method at this tier. Convert
create_udp_channel to return the local socket side of the datagram
abstraction presented analogous to the TcpClientChannel approach
used before.
-----
Notes and intricacies:
In order to implement recvfrom on the UDP abstraction, a shim layer
has been put in place to forward the sockaddr information from the
remote peer to the local UDP socketpair in the abstraction. This
information takes up buffer space in the UDP socket, and in order
to maintain compatibility with consumers, the dio_write_handler
pushes the data buffer, and in a separate send call, he sockaddr
information from the remote socket. On the abstraction side, the
recvfrom_nonblock call of the real UDPSocket has been overriden
via the mixed in module to call the real method twice, once for
the data buffer, and once for the packed sockaddr data. The Rex
level consumer for recvfrom calls the underlying nonblock method
and expects this exact set of returns (as opposed to what standard
library UDPSocket.recvfrom returns, which is a data buffer and an
Array of sockaddr data).
-----
Testing:
Local and lab testing only so far.
Test RC script to be added in GH comments.
-----
Issues:
Currently, sendto on a remote socket does not appear to honor
LocalPort which causes DNS responses (#6611) to come from the
wrong port to remote clients being serviced over a pivot socket.
the preauth fingerprinting for postgres is somewhat
unmaintainable, but due to a specific customer request
i have added these two FPs for 9.4.1-5
MS-1102
A warning is emitted since there is a potential for data loss, but since
we reference vulns by their ID, the data-integrity risk is small.
Initially triggered by some Nexpose data, this should probably be
properly fixed by removing the length bound on the field.
MS-1184
Ubuntu has this glib bug (g_slice_set_config) that results us
seeing a bunch of warnings when we call system("firefox") in
Ruby. It doesn't look like our fault, but since this generates
a lot of text on msfconsole, we try to avoid that.
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
Brent Cook
OJ
Brendan Watters
wchen-r7
James Lee
Gregory Mikeska
Till Maas
Louis Sato
Metasploit
Adam Cammack
William Vu
RageLtMan
David Maloney
HD Moore
Christian Mehlmauer
Tim
Spencer McIntyre
Brian Patterson
Fernando Arias
HD Moore