msfcli is no longer supported, please use msfconsole.
Announcement on SecurityStreet:
Weekly Metasploit Wrapup
Posted by Tod Beardsley in Metasploit on Jan 23, 2015 11:57:05 AM
This fixes a huge number of hard-to-detect runtime bugs
that occur when a default utf-8 string from one of these
libraries is passed into a method expecting ascii-8bit
so we shouldn't have to load all of them to run this utility. The
overall goal of this PR is to narrow down what modules
(exploit/aux + payload + encoder + nop) you possibly need in order
to shave off loading time. By doing this, on my box this is 5-6
seconds faster than the original one.
I actually tried to avoid making too many changes in the library
(such as Module Manager), because we don't have test cases for them,
and we can't really afford to risk breaking it. I also developed
a test script to actually be able to test msfcli.
Instead of deleting all non-symbolics before the re-adding phase of
PayloadSet#recalculate, store a list of old module names, populate a
list of new ones during the re-adding phase, and finally remove any
non-symbolic module that was in the old list but wasn't in the new list.
Also includes a minor refactoring to make ModuleManager its own thing
instead of being an awkard subclass of ModuleSet. Now PayloadSet doesn't
need to know about the existence of framework.modules, which makes the
separation a little more natural.
[FixRM #7037]
[Fixes#38426061, #38097411]
Msf::Modules::Loader::Directory#read_module_content may calculate a non-existent
module_path that gets passed to File.open causing an Errno::ENOENT exception
to be raised when using the module cache with a module that has been
moved to a new path (as is the case that originally found this bug) or
deleted. Now, the exception is rescued and read_module_content returns
an empty string (''), which load_module detects with
module_content.empty? and returns earlier without attempting to module
eval the (empty) content.
As having Msf::Modules::Loader::Directory#read_module_content rescue the
exception, meant there was another place that needed to log and error
and store an error in Msf::ModuleManager#module_load_error_by_path, I
refactored the error reporting to call
Msf::Modules::Loader::Base#load_error, which handles writing to the log
and setting the Hash, so the error reporting is consistent across the
loaders.
The exception hierarchy was also refactored so that
namespace_module.metasploit_class now has an error raising counter-part:
namespace_module.metasploit_class! that can be used with
Msf::Modules::Loader::Base#load_error as it requires an exception, and
not just a string so the exception class, message, and backtrace can be
logged.
[Fixes#37630057]
Modules were always being detected as having file changes because the
parent_path directory, instead of the actual module_path, was being
passed to module_manager.file_changed?, which caused the modification
times to not match.
To ensure this change fixes the ambiguous module warnings, a full spec
for Msf::Core::Modules::Loader::Base has been written.
spec/msf has moved to spec/lib/msf to match conventional spec layout and
allow for the spec/support directory to not be confused as a lib
subdirectory being tested.
dwelch-r7