The original URI is registered as '/foobar/' but is deregistered as
'//foobar/', causing it to never get deregistered. Changing this fixes
unregistration of the service handler for staged payloads, but stageless
doesn't work properly if the URI actually gets deregistered.
Rather than listening forever after a session shuts down, close the session if
there are no other URI's registered on the listener. This allows reconfiguring
the listener without restarting framework, but should be safe for situations
where multiple modules share the same listener.
So, metasm generates labels for the assembler using "%x" % string.object_id. If
the pointer for string.object_id begins with the most significant digit set, it
looks like a sign-extended 2's complement number (negative), and gets formatted
by ruby as '..f1412300' or similar. On 32-bit platforms, there is rather high
chance of randomly ending up with a label like 'goto_test_uuid..f1234560:',
which is a parse error.
This patch simply takes the absolute value of the object_id to avoid negative
interpretations. This fixes hiesenbugs using metasm's C compiler on 32-bit
platforms.
This fixes#4866, an issue with msfvenom not properly handling special
cases with generic payloads. So the story behind this fix is that
we have these two problems:
Problem 1: The current payload selection design relies on the payload
module in order to set the platform and arch. Almost all MSF payloads
contain a default platform and arch, however, the bind and reverse
generic payloads don't.
Problem 2: By default, Msf::Payload::Generic also explicitly sets the
PLATFORM and ARCH datastore options to nil. So there is no way the
payload generator can figure out what platform and arch to use.
As a result of these problems, msfvenom will actually end up getting
a Msf::Module::Platform as the default platform, which doesn't
actually represent any valid platform we can use (such as
Msf::Module::Platform::Windows). And the first item of ARCH_ALL for
the arch.
In addition, msfvenom has these two arguments that the user can use:
--platform and --arch. In most cases, these arguments are used more
like checks than actually setting anything. Because remember:
Framework's payload selector retreives the platform & arch from the
module (trusted), not the user input (untrusted). But from the user's
perspective it's impossible to know this.
After experimenting different ways to fix this, I came up with this
patch. It feels sort of more like a hack than a real fix, but as
far as I can tell, this is the best you can get unless you want to
redesign generic payload selection.
benpturner
Brent Cook
OJ
William Vu
Christian Mehlmauer
joev
Luke Imhoff
Tod Beardsley
sinn3r
root
rwhitcroft
root
HD Moore
sekritskwurl