All of the existing kernel_release code looks fine to me for the example "funky" version string 5.4.129-72.229.amzn2int.x86_64. Was there another version string causing issues?

This code splits at the first -. Rex::Version receives 5.4.129 which is valid and will not raise.

Edit: modules/exploits/linux/local/vmwgfx_fd_priv_esc.rb does no prior parsing of kernel_release and will raise.

The package parsing code does no prior parsing of the version before passing to Rex::Version and will likely raise.

The kernel_release code is good, it returns as expected. That test string won't load well into Rex::Version, so we either need to guard on getting something from kernel_release that won't cleanly load into a Rex::Version, or do some post filtering (typically done with software package versions, less so kernel releases) to make it load correctly.

This is just want I was seeing in an engagement and wanted to fix some crashes that exploit_suggester was seeing

I'll be testing these changes on target to make sure its handling better, and get some more test data.

@bcoles

Fedora 31 target (vm) I'm getting the following:

[msf](Jobs:2 Agents:1) exploit(linux/local/netfilter_xtables_heap_oob_write_priv_esc) > check
[-] Exploit failed: RuntimeError Could not determine grsecurity status
[-] Check failed: The state could not be determined.

This is caused by https://github.com/rapid7/metasploit-framework/blob/master/lib/msf/core/post/linux/kernel.rb#L262 . Which looks like its checking on the LOCAL (metasploit) system, not the remote (exploited) system. Just wanted to confirm if that was right and if that was the expected behavior.

@bcoles

Fedora 31 target (vm) I'm getting the following:

[msf](Jobs:2 Agents:1) exploit(linux/local/netfilter_xtables_heap_oob_write_priv_esc) > check
[-] Exploit failed: RuntimeError Could not determine grsecurity status
[-] Check failed: The state could not be determined.

This is caused by https://github.com/rapid7/metasploit-framework/blob/master/lib/msf/core/post/linux/kernel.rb#L262 . Which looks like its checking on the LOCAL (metasploit) system, not the remote (exploited) system. Just wanted to confirm if that was right and if that was the expected behavior.

That is definitely checking the local file which is definitely wrong.

The grsec_installed? method was added in d87fef5 and checks the remote file.

The breaking change was introduced in f5145de (#19405).

@jvoisin any background on that change?

Dang, I thought that File.exists?('/dev/grsec') && File.chardev?('/dev/grsec') would check the remote system :/

This seems like something that would be good functionality to move into post/linux/kernel as a function. I see we already have kernel_version but something with an intuitive name that would return an instance of Rex::Version so this kind of normalization is centralized would be beneficial in the future. It would be a good idea to do the exception handling within the method as well and just return nil to the caller so they can do what they want in the event that they can't get a Rex::Version instance.

Maybe something like kernel_rex_version?

I'm particularly concerned about this because of the one case where the string is rejoined in the case of Ubuntu.

I like the idea, but I think that needs to be handled outside of this PR. I think a bunch of different kernel releases from different flavors will be required in a pretty big spec to make sure we handle all the cases. For instance, Ubuntu has kernels like 5.13.0-37.42 from the docker cgroup exploit, and 5.4.129-72.229.amzn2int.x86_64. Seems like an easy split/regex, \d{1}\.\d{1-3}\.\d{1-4}\-\d{1-3}\.\d{1-4}. But gathering that data will take some time.