-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Meterpreter compatibility requirements to lib #15842
Add Meterpreter compatibility requirements to lib #15842
Conversation
stdapi_sys_process_* | ||
stdapi_sys_process_execute | ||
stdapi_sys_process_get_processes | ||
stdapi_sys_process_kill |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core_channel_open
might be needed for cmd_out.channel.read
on line 257 of the updated file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe should be core_channel_close
and core_channel_read
given its closing and reading from channels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a entirely unrelated note we should really have a list centralized somewhere of each of these extension names and what they are used for; its a pain atm looking it up across multiple files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spot, will need to add this in a separate PR 👍
stdapi_sys_config_getprivs | ||
stdapi_sys_config_getuid | ||
stdapi_sys_process_execute | ||
stdapi_sys_process_get_processes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that each_service
here calls session.extapi.service.enumerate.each(&block)
if extapi is loaded as per
metasploit-framework/lib/msf/core/post/windows/services.rb
Lines 151 to 154 in c8f1c84
def each_service(&block) | |
if load_extapi | |
session.extapi.service.enumerate.each(&block) | |
else |
extapi_service_enum
?
It does fall back but I mean the way this and other code particularly registry code is coded is that it hugely depends on if extapi
is loaded and if it is but the Meterpreter doesn't support that feature, then things kinda get very odd and messed up very fast.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with
metasploit-framework/lib/msf/core/post/windows/services.rb
Lines 244 to 253 in c8f1c84
def service_info(name) | |
service = {} | |
if load_extapi | |
begin | |
return session.extapi.service.query(name) | |
rescue Rex::Post::Meterpreter::RequestError => e | |
vprint_error("Request Error #{e} falling back to registry technique") | |
end | |
end |
Do we want to require extapi_service_query
here as a result?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core_channel_read
and core_channel_close
potentially required here due to the way run_cmd
operates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that each_service here calls session.extapi.service.enumerate.each(&block) if extapi is loaded as per
That will be covered by the mixin that provides the each_service function:
metasploit-framework/lib/msf/core/post/windows/services.rb
Lines 51 to 52 in c9af078
extapi_service_enum | |
extapi_service_query |
core_channel_read and core_channel_close potentially required here due to the way run_cmd operates.
Will lump this in with the implicit nature of stdapi_sys_process_execute being associated with channel open/close/read/eof, can iterate on this in a future PR though 👍
Pinging @adfoster-r7, any updates on fixing these issues? Only asking as its been nearly a month since the last review. If no time that's fine just want to make sure we have a status update on this so people looking at this PR know what is going on. |
c9af078
to
9dece7e
Compare
9dece7e
to
48f4007
Compare
Cross-referencing #15949 too This PR should fix the issue which stopped modules running as part of the local exploit suggester, as |
To clarify before landing there are a few features here that we still need to iterate on and improve. Namely they are: Comments at #15842 (comment) and previous comments r.e Comments at #15842 (comment) and #15842 (comment) r.e Comment at #15842 (comment) r.e creating a centralized list of requirements and what each one is actually used for in some form of documentation. I'm happy to investigate this further in 2022 but will likely need some assistance as some feature have some edge cases that @adfoster-r7 or similar might have better insights into. For now though this PR is fine and @adfoster-r7 and I both agree this is a good point to pause and land existing work, with the understanding that the automation needs to be improved and run again across the codebase, and that further iteration and improvements are needed on the above issue along with the documentation note as mentioned above. |
Release NotesSeveral libraries within the |
Updating the Meterpreter compatibility requirements for mixins within the lib folder
Building on the work of #15295 and #15659
Verification
Review the modules and verify that the command additions make sense