metasploit-framework icon indicating copy to clipboard operation
metasploit-framework copied to clipboard

Improve flimsy architecture detection

Open bcoles opened this issue 5 months ago • 0 comments

Much of the platform and architecture detection code within Framework and accompanying libraries has grown naturally as needed over the past 20 years.

Many patches and enhancements were implemented as needed, usually in a manner similar to the following:
  1. x64 is new, let's add support! If the arch detection fails then it must x64
  2. x86 is old school - we're all about x64 now. Let's check a version string for 64, and if it's not x64 then it must be x86
  3. ARM is becoming popular. If the x86 / x64 detection fails then it must be ARM. Let's check for ARM first (32-bit of course), then fall back to x86 / x64 detection
  4. x64 means x86_64, but there are other 64 bit architectures. Even ARM is 64 bit now.
  5. ...
  6. If it doesn't match <large collection of string comparison conditional statements>, then assume it's x86

This evolution is not unique to Metasploit and has played out many times across many projects.

The resulting code patterns are often brittle. In particular, in instances where:

  • anything containing 64 is expected to be x86_64, ignoring 64-bit ARM and RISC-V (and MIPS64 and LoongArch64 and SPARC64 and ...).
  • anything that isn't _________ is presumed to be __________. (ie; anything that isn't <expected architectures> is presumed to be x86)

This will become more of an issue due to the increasing popularity of ARM (OSX on Apple M1 and official support for running Windows on ARM) and RISC-V.

Issues will also arise with a lot of the Windows Meterpreter code if we ever add ARM native Meterpreter (#15025).

We have Msf::Post::Architecture now, which is a good start for local execution on Windows platforms.

Creating a thread to track instances where this should be addressed in Framework and supporting libraries.

Feel free to edit this post, post in this thread, or creating a new issue referencing this issue.


Modules

https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/modules/exploits/windows/local/payload_inject.rb#L61-L63


https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/modules/exploits/windows/local/applocker_bypass.rb#L51-L53


https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/modules/exploits/multi/http/jboss_maindeployer.rb#L347-L358


Libraries

MySQL (arm is supported; RISC-V is not officially supported yet)

https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/rex/proto/mysql/client.rb#L56-L82

MSSQL:

https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/rex/proto/mssql/client.rb#L92-L110

PostgreSQL for comparison:

https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/postgres/postgres-pr/connection.rb#L177-L208


https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/msf/core/exploit/remote/mysql.rb#L190-L211


https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/msf/core/exploit/remote/http_server.rb#L337-L352


https://github.com/rapid7/metasploit-framework/blob/f20dcb27ddf5b31157b124e274a0df209e72126b/lib/msf/core/exploit/remote/http/jboss/base.rb#L125-L140

bcoles avatar Sep 17 '24 08:09 bcoles