This also fixes an issue with report_vuln() from exploited hosts not
setting the service correctly. This introduces a fail_reason method
to the exploit base class, which attempts to determine why an exploit
did not work (closed port, unreachable host, missing page, etc). There
is still quite a bit of work to do around this to finish it up.
The purpose of re-raising an error from a library method like this is to
tell the user in no uncertain terms what all actually went wrong with the
module. This fix will cause a somewhat more pleasant error message than
the default message. Here's the raise from URI:
```
[-] Auxiliary failed: URI::InvalidURIError bad URI(is not URI?): what%ever
[-] Call stack:
[-] /home/todb/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/uri/common.rb:156:in `split'
[-] /home/todb/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/uri/common.rb:174:in `parse'
[-] /home/todb/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/uri/common.rb:626:in `parse'
[-] /home/todb/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/uri/common.rb:724:in `URI'
[-] /home/todb/git/rapid7/metasploit-framework/lib/msf/core/exploit/http/client.rb:535:in `target_uri'
[-] /home/todb/.msf4/modules/auxiliary/test_uri.rb:20:in `run'
[*] Auxiliary module execution completed
```
And here's the new, Metasploit-specific one:
```
[-] Invalid URI: "what%ever"
[-] Auxiliary failed: Msf::OptionValidateError The following options failed to validate: URIPATH.
[*] Auxiliary module execution completed
```
The user can now tell easily what's wrong with the module configuration,
and doesn't have to parse through a stack trace that leads down into
the Ruby stdlib.
HD Moore