See #4400. This should be all of them, except for, of course, the module
that targets Redmine itself.
Note that this also updates the README.md with more current information
as well.
The tool produces A LOT OF results so it's really painful to manually
copy and paste and to be able to use the data. So it should automatically
save.
Tagging the issue here because I forgot to do it:
Fix#4039
MSP-11145
**NOTE: Failing specs**
Add a tool for reading `log/untested-payload.log` and
`framework.payloads` to determine `context`s to add
`spec/modules/payloads_spec.rb` to test the untested payloads.
See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in
MSP-11368
MSP-11143
Remove fastlib as it slows down the code loading process. From the
previous commit, the mean loading for
`METASPLOIT_FRAMEWORK_PROFILE=true msfconsole -q -x exit` was
27.9530±0.3485 seconds (N=10). The mean after removal of fastlib
was 17.9820±0.6497 seconds (N=10). This means an average 35.67%
reduction in boot time.
Rubocop replaces the default YAML library which makes development
testing difficult. It does not cause problems on Travis, but according
to reports, it does cause instability with many individual dev
environments.
While I would love to have a more solid source of this bug report, right
now this was an oral report from @shuckins-r7 (who I tend to believe a
lot).
There are still strong reservations about using Nokogiri to parse
untrusted XML data.
http://www.wireharbor.com/hidden-security-risks-of-xml-parsing-xxe-attack/
It is also believed that many desktop operating systems are still
shipping out-of-date and vulnerable libxml2 libraries, which become
exposed via Nokogiri. For example:
http://stackoverflow.com/questions/18627075/nokogiri-1-6-0-still-pulls-in-wrong-version-of-libxml-on-os-x
While this isn't a problem for binary builds of Metasploit (Metasploit
Community, Express, or Pro) it can be a problem for development
versions or Kali's / Backtrack's version.
So, the compromise here is to allow for modules that don't directly
expose XML parsing. I can't say for sure that the various libxml2
vulnerabilities (current and future) aren't also exposed via
`Nokogiri::HTML` but I also can't come up with a reasonable demo.
Metasploit committers should still look at any module that relies on
Nokogiri very carefully, and suggest alternatives if there are any. But,
it's sometimes going to be required for complex HTML parsing.
tl;dr: Use REXML for XML parsing, and Nokogiri for HTML parsing if you
absolutely must.
It's often you want counts of just WARN and ERROR messages, and don't
want to spam yourself with INFO messages that you don't intend to
address anyway. This is most often the case with CI, such as with
https://travis-ci.org/todb-r7/metasploit-framework
This correct msftidy's disclosure date check to do the following:
1. If the module has a disclosure date, the check should kick in.
2. If the module is an exploit, and doesn't have a disclosure
date, then it will be flagged.
3. If the module is an auxiliary, and doesn't have a disclosure
date, then it will NOT be flgged (because not all aux modules
target bugs/vulns like exploits do).
This will make it possible to run a post-merge check when
pre-commit-hook.rb is referenced as a symlink from .git/hooks/post-merge
The kind of check you're going to do is entirely dependant on the
basename of the file, which is a little weird but convenient.
Verification is a little tricky on this. Coming soon.
Nokogiri has a habit of shipping vulnerable builds of libxml2. For
example, see this:
http://www.ubuntu.com/usn/usn-1904-1/
and compare to Nokogiri's bundled requirements:
https://github.com/sparklemotion/nokogiri/blob/master/dependencies.yml
While Nokogiri is quite pleasant to use, it really shouldn't be trusted
to handle potentially malicious data. Imagine if a "vulnerable" target
was actually a malicious honeypot, lying in wait for a poor Metasploit
user to come along and parse out its payload. (OT: does such a thing
have a clever name? If not, I propose "beehive" to imply the offensive
capabilities of such a honeypot.)
Nokogiri is used elsewhere in Metasploit, but those functions handle
data sourced from the Metasploit user herself, so those XML hunks are
nominally trustworthy.