Mettle stages trigger PAX MPROTECT

[sempervictus]

Using linux/x86/mettle/reverse_tcp to generate a stage0, then uploading it an arch box with a "pretty much all options on" grsec config results in this fine mess:

denied RWX mmap of /root/met86.bin by /root/met86.bin[met86.bin:8690] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/bash[bash:8675] uid/euid:0/0 gid/egid:0/0

which, without further provocation than the single exec of the bin, triggers the brute force protection stalling forks and making sadness:

bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds.  Please investigate the crash report for /usr/bin/bash[met86.bin:8690] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/bash[bash:8675] uid/euid:0/0 gid/egid:0/0

[timwr]

Do you get this with linux/x86/shell/reverse_tcp or linux/x86/mettle_reverse_tcp?
Is it https://github.com/rapid7/metasploit-framework/blob/master/modules/payloads/stages/linux/x86/mettle.rb#L45
or maybe https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/linux/ia32/stager_sock_reverse.asm#L70 ?

[sempervictus]

Yeah, the mprot settings there will need to go.
Confirmed with shell/rev_tcp stage:

denied RWX mmap of /root/shell.bin by /root/shell.bin[shell.bin:9494] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/bash[bash:8843] uid/euid:0/0 gid/egid:0/0

Also confirm that stageless mettle runs (not sure if it WORKS after recent changes, didnt see a session). PAX is working as intended, and if understand intent correctly, we wont be able to simply split up the mprotect calls from our modifications as i dont think it'll let us re-mark memory after altering it.

[sempervictus]

So... things in the ecosystem are changing on this front, but for the sake of staying on the subject of mprotect, this is going to get a lot worse for us when SARA or the tpe mprot code lands upstream. We probably want to figure out other methods for doing this, since @OJ so correctly pointed out that encoders want RWX to decode.

[OJ]

I sense some horrible encoder work coming! And I wouldn't be surprised if we end up in a world of hurt thanks to badchars.

[sempervictus]

On the bright side, shows the state of affairs from the blue side viewpoint improving, sort of. To make all this so much more fun, there's another LSM in the works to stop commandline dynamic script language invocation vectors.