Linux reverse_tcp should read known # of bytes

[sempervictus]

The linux x64 reverse tcp stager is hardcoded to read 4K off the
socket. When a small intermediate stager is used, this can result
in reading part of the next stage as well, which means that the
intermediate stager will never recv the # of bytes it needs and
hang indefinitely.

Break out the mettle piece to use separate methods for assembly and
binary payload generation as well as actually putting the product
on the existing session socket.

Change the first part of the stage to check for the intermediate
stager generation method, and use the size of the produced stager
in the recvfrom call or fall back to the prior 4K read size.

Testing:
None yet

Ping @bcook-r7, @acammack-r7, @OJ, @zeroSteiner

[bcook-r7]

Note, the same problem is in other stagers, e.g. x86 also does a blind read.

[timwr]

Surely the payload is now just reading a hardcoded 126 bytes instead of 4096. What if we update the stager in the future so that it's more than 126 bytes? Any previously generated payload will only read 126 bytes and fail. Perhaps it might be better to first read the length and then mmap/read that number of bytes. We do this on aarch64 (and java):

metasploit-framework/external/source/shellcode/linux/aarch64/stager_sock_reverse.s

Line 33 in 288bb56

/* read(sockfd, buf='x1', nbytes=4) */

[timwr]

Is the current behaviour causing issues? There was a bug on OSX that occurred occasionally but it was fixed with a rex.sleep: #11165 potentially we could fix them both at once to use a length (and metasm).

[sempervictus]

Current behavior is broken. The dynamic read size should be a payload option IMO, and your midstager would have to differ for this to break, actual stage doesn't matter.
Also all for dynamic read sizing as an option...

[acammack-r7]

I think I prefer this to the timing-based approaches we've used in the past to separate the intermediate stager from the stage on the wire. There are some asm hygiene items to fix, though.

[acammack-r7]

@bwatters-r7 Will also be interested, I think.

[sempervictus]

Thank you. x86 likely as well since we are moving the size param to edx

[acammack-r7]

Not in the default case. When it's not a meterpreter stager it acts just as it did before, it is just a bit more explicit about what it's doing. Also, when the intermediate stage is short (like it is now), the size fits into a single byte, so the stage still doesn't grow.

[acammack-r7]

The x64 stager looks to be oscillating in size, I'll dig into it.

[acammack-r7]

Release Notes

Previously on Linux, the x86 and x64 reverse TCP stagers would often read past the end of Meterpreter's intermediate stager and grab the first few bytes of the final Meterpreter payload. Both stagers now only read the expected number of bytes as a hot fix. This makes them more reliable pending reworking them to read the size of the next stage off the wire as done on other platforms.