Also replaces dead code in lib/msf/core/exploit/local.rb with what was
actually being used for the Exploit::Local class that lived in
lib/msf/core/exploit.rb.
Aside from codebase-wide changes, nearly all of these tests haven't been
touched since before 2010, and there is no effort to maintain this style
of testing. We've moved on to (correctly) seperating out our tests from
our codebase.
This function takes advantage of MSTIME's CTIMEAnimationBase::put_values
function that's suitable for a no-spray technique (based on wtfuzz's
PoC for MS13-008)
When a module is configured to listen on the INADDR_ANY interface, with
a payload that does not have an LHOST option, it attempts to determine
the srvhost from a client socket which would only be available when the
module has included the TcpClient mixin (i.e., it is both passive and
aggressive stance), causing a NameError for the undefined +sock+.
This commit fixes the problem in two ways:
1. It changes the default cli in get_uri to be the module's self.cli,
which should always be set when passive modules would need it (e.g., in
the on_request_uri method).
2. It adds a check to make sure that the calling module has a sock
before trying to get its peerhost. This was @marthieubean's suggested
solution in #1775.
[Closes#1775]
Update Rex::Socket::SslTcp to accept verification mode string from
Rex::Socket::Parameters, which has been modified accordingly.
Add SSLVerifyMode and SSLCipher options (params and socket work
were done before, but the option was not exposed) to
Msf::Exploit::Tcp.
Testing:
```
>> sock = Rex::Socket::Tcp.create('PeerHost'=>'10.1.1.1','PeerPort'
=>443,'SSL' => true, 'SSLVerifyMode' => 'NONE')
>> sock.sslctx.verify_mode
=> 0
>> sock.close
=> nil
>> sock = Rex::Socket::Tcp.create('PeerHost'=>'10.1.1.1','PeerPort'
=>443,'SSL' => true, 'SSLVerifyMode' => 'PEER')
=> #<Socket:fd 13>
>> sock.sslctx.verify_mode
=> 1
```
Note: this should be able to resolve the recent SSL socket hackery
of exploit/linux/misc/nagios_nrpe_arguments.
[#46491831]
Comments at the start of the file with ## caused YARD to think the
comment was documenting the require call. By removing the ##, the
warning disappeared. I did not determine what is special about ## in
file comments.
James Lee