MSP-11130
`Metasploit::Framework::Spec::Constants::Each.configure!` will set up an
`after(:each)` callback that will fail the example if there are leaked
constants. Leaked constants are cleaned up to prevent misattribution.
MSP-11130
`Metasploit::Framework::Spec::Constants::Suite` extracts out
`LOG_PATHNAME`, `configure!`, and `define_task` as those piece are
specific to handling constant leaks for the entire suite. This is in
preparation for `Metasploit::Framework::Spec::Constants::Each`.
In the reported case, the expected cookies were not present on the
response, thus, the second split was trying to split a `nil`. This
solves the immediately problem by a) splitting up the splits into
discrete sections, and b) `NilClass#to_s`'ing the result of the first
split.
This makes the split safe. Now, there may be a larger issue here where
you're not getting the expected cookies -- it sounds like the target in
this case is responding differently, which implies that the module isn't
going to be effective against that particular target. But, at least it
won't crash. It may merely try fruitlessly the entire run, though. I
can't know without looking at a pcap, and in the reported case, a pcap
seems unlikely since this was a bug found in the field.
MSP-11130
Constants from library Modules or Classes should not be reported as
leaked since they have been required and should be persistent between
spec runs.
MSP-11130
Extract method to convert child constant names to module full names so
it can be reused 'Metasploit::Framework::Spec::Constants tracker' shared
context.
MSP-11130
Instead of printing the leaked constants to stderr, log them to
`log/leaked-constants.log`. In task action for spec, read
`log/leaked-constants.log`. If it exists, print each leaked constants
(and it appropriate it's module full name) and then exit with 1. If the
file does not exist, do nothing.
This makes it somewhat easier to use FTP server exploit modules in
somewhat more restrictive networks, where you might only have a few
inbound ports to choose from.