rapid7/metasploit-framework — pull request #2935 by todb-r7 (2014-02-02 18:13:20+00:00)
Title: Modules shouldn't use Nokogiri

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.

## Verification steps

**Pre-patch**

- [ ] Run `tools/msftidy.rb modules | grep Nokogiri` and note the lack of hits.

**Post-patch**

- [ ] Run `tools/msftidy.rb modules | grep Nokogiri` and note two hits -- one on `canon_wireless.rb` and one on `mswin_tiff_overflow.rb`

## TODO:

* Once this lands, those modules should be re-written to use `REXML` rather than `nokogiri` in order to excise the existing Nokogiri usages in modules.
* A module that exploits the existing Canon Wireless module by pretending to be vulnerable. It's unclear to me right this second if `Nokogiri::HTML()` provides a path to code execution.

Note the other use of Nokogiri is merely using Nokogiri to build an XML file in the context of a `FILEFORMAT` module, so it looks impossible to exploit.