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?