Add ForceExploit to Linux local modules

[bcoles]

Add ForceExploit option to various Linux local exploits.

Some of these changes are more useful than others. In most instances, if a well-written check method says that the remote host it not exploitable, then the remote host is not exploitable. None the less, it's nice to have options.

Of particular note is allowing ForceExploit to bypass the is_root? check (which traditionally has been performed inside the exploit method, rather than inside check). This is important, as the is_root? check is not namespace safe. It will return true when UID=0, however it's possible to have UID=0 in a namespace without being "real" root. It's probable that a user with root in a namespace will wish to launch a kernel exploit to escape the namespace and gain elevated privileges. Prior to this PR, this workflow was not possible without modifying the module source.

The is_root? check was only ever performed to prevent operator error. As such, the operator should have a way to bypass it if they so desire.

[h00die]

Looks logical to me, its more or less a repeat across a ton of modules minus the one print_error to vprint_error

[bcoles]

Bump. This PR does something useful.

Talk of implementing automatic CheckCode checking at the framework level is fanciful daydreaming. It was daydreaming when mentioned more than six months ago; and it will be daydreaming in 2019.

Why must this PR rot in the presence of daydreams?

[wvu]

wvu@kharak:~/metasploit-framework:master$ git log -SForceExploit --reverse modules
commit c8b6482ab012a32e462d9f129a4f0f4d852d2a63
Author: William Vu <William_Vu@rapid7.com>
Date:   Tue Apr 24 00:02:15 2018 -0500

    Rewrite PHP targets to work with 7.x and 8.x

    Win some, lose some. php -r spawns a new (obvious) command. :/

    Check method and version detection also rewritten. :)

commit 41b0adad8845fa3d1615888b14ff78f5ff7cc0f7
Author: William Vu <William_Vu@rapid7.com>
Date:   Tue Jul 3 11:50:22 2018 -0500

    Use uninstall action command injection

commit 4b62f413692f45e874a5278abe3996f473da41ce
Author: Brendan Coles <bcoles@gmail.com>
Date:   Thu Jul 12 20:00:17 2018 +0000

    Add QNAP Q'Center change_passwd Command Execution exploit

commit 1e004769caa7d6499506606debf3f6ed9c60ce52
Author: Jacob Robles <jrobles@rapid7.com>
Date:   Tue Jul 17 09:00:39 2018 -0500

    CMS Made Simple Upload/Rename Authenticated RCE

commit e75b5592f75e1de4f5705937cee26cd211b22731
Author: Brendan Coles <bcoles@gmail.com>
Date:   Tue Sep 11 09:23:50 2018 +0000

    Add ForceExploit option

commit 2f5bd4b71499ff0fa9ada267bc0d1c53044a36a6
Author: Brendan Coles <bcoles@gmail.com>
Date:   Tue Sep 18 07:23:10 2018 +0000

    Add Solaris 'EXTREMEPARR' dtappgather Privilege Escalation module

commit 4fb223b293ae67c13cb1aa5a8f6e245129271088 (upstream/pr/10668)
Author: Brendan Coles <bcoles@gmail.com>
Date:   Tue Sep 18 17:38:59 2018 +0000

    Add Solaris RSH Stack Clash Privilege Escalation module
wvu@kharak:~/metasploit-framework:master$

This already has traction, and it's an important option to have.

[wvu]

Release Notes

This adds the ForceExploit option to Linux local exploits to opt out of a check method's return value during the exploitation phase.

[wvu]

I am implicitly endorsing ForceExploit as the standard until we can just do it and not let our dreams be dreams.