Fix arbitrary size of payloads on functionally unlimited space exploits.

[bwatters-r7]

Idea:

While testing and merging https://github.com/rapid7/metasploit-framework/pull/6954 with @wvu-r7 , I noticed that we require length in all exploits. That does not make a lot of sense for many local exploits that have practically unlimited space for payloads.

Currently, the method is to give an arbitrary "large" payload value and hope for the best. I think a better solution would be to allow a nil value for space on a given exploit, and that should allow the use of any sized payload.

Example:

Line 36 in lib/msf/core/payload/linux/reverse_tcp.rb: if self.available_space && required_space < self.available_space

should be: if self.available_space.nil? || required_space < self.available_space

That way, exploit authors that have no constraints on size could simply declare size as nil, or not bother to provide the information. Otherwise, he/she must randomly pick an arbitrarily-large payload size limit that could cause trouble later.

The catch is that I do not know exactly how much this could affect. It could simply be a change to 15-20 payload files, but I'm not versed in the library well enough to understand the full implications.

[egypt]

I think I'd rather have a specific value that means unlimited with nil being an error so module authors have to consciously choose to have unlimited space.

[bwatters-r7]

A good and valid point, sir. Perhaps 0 for unlimited and nil for error?

[adfoster-r7]

@bwatters-r7 Is this ticket still relevant? 👀

[bwatters-r7]

Probably more so now as we support more exploits that have functionally unlimited payload sizes. I'd also be curious about how our new cmd-based payloads work within the size constraints, TBH. This was a bit of the issue we hit when we did the fetch payloads- it seemed the stager code was generated with the erroneous belief that it needed to be super tiny when it could have been pretty much unlimited.