xiphosresearch / netelf Goto Github PK

e.g. Bash on Windows, or 'Linux' zones in Solaris...

__NR_memfd_create is a preprocessor macro, so we can test for it's existence at compile-time and disable code which uses that syscall.

At runtime we already check for errno == ENOSYS, presumably Bash on Windows will act accordingly so the shm_open fallback can be run.

If shm_open fails, which is really just a wrapper around opening from /dev/shm, then the portable UNIX-like file_exec will be used.

Original commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c

Another interesting option is O_TMPFILE, supported since Linux 3.11, whereas memfd_create is supported only in Linux 3.17, it's unlikely that either are supported by 'Bash on Windows':

          Specifying O_EXCL in conjunction with O_TMPFILE prevents a
          temporary file from being linked into the filesystem in the
          above manner.  (Note that the meaning of O_EXCL in this case
          is different from the meaning of O_EXCL otherwise.)

          There are two main use cases for O_TMPFILE:

          *  Improved tmpfile(3) functionality: race-free creation of
             temporary files that (1) are automatically deleted when
             closed; (2) can never be reached via any pathname; (3) are
             not subject to symlink attacks; and (4) do not require the
             caller to devise unique names.

          *  Creating a file that is initially invisible, which is then
             populated with data and adjusted to have appropriate
             filesystem attributes (fchown(2), fchmod(2), fsetxattr(2),
             etc.)  before being atomically linked into the filesystem
             in a fully formed state (using linkat(2) as described
             above).

          O_TMPFILE requires support by the underlying filesystem; only
          a subset of Linux filesystems provide that support.  In the
          initial implementation, support was provided in the ext2,
          ext3, ext4, UDF, Minix, and shmem filesystems.  Support for
          other filesystems has subsequently been added as follows: XFS
          (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs
          (Linux 4.9)

Is it possible to send a shared object to netelf, then have it execute a local program with arguments and an LD_PRELOAD environment variable pointing to an fd created with memfd?

In _win32.c and netelf.c the default IP address and port is hard-coded.

Need to be able to customise it at compile time, either by editing a config.h file or via -D defines.

CreateProcess doesn't take an argv style array of pointers.

Need to concatenate & escape arguments into a single string...

On Windows use MemoryModule, on Linux just dlopen the file or socket.

argv[0] should be the symbol name to load and call.

Then call the symbol with:

symbol(socket_handle, argc, argv);

fexecve is defined in the IEEE Std 1003.1-2008 (POSIX.1-2008) standard, however it's not so widely supported by the libc of various different systems.

The aim is to avoid creating our own executable/library loader, and avoid ever writing to the filesystem as that leaves an audit-trail of sorts.

The underlying premise for Unix-like platforms relies having one of two options available:

1. Have a /proc filesystem where open file descriptors can be accessed like regular files and passed to exec like normal paths.
2. Have a libc or kernel system call which performs special handling of file descriptors to exec them directly, aka fexecve.

For Windows platforms there are two options available:

1. Hook ntos.dll calls so when it tries to load an executable / library you can read from a buffer
2. Re-implement the loader, e.g. MemoryModule or the various Meterpreter EXE loaders.

Man pages and related info for fexecve on non-Linux platforms:

• POSIX / opengroup - http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html
• https://www.freebsd.org/cgi/man.cgi?query=fexecve&sektion=2
• https://docs.oracle.com/cd/E36784_01/html/E36872/fexecve-2.html
• Illumos - https://illumos.org/issues/5798
• AIX v7.1 - http://www-01.ibm.com/support/docview.wss?uid=isg1IV26545
• Cygwin - https://github.com/mirror/newlib-cygwin/blob/f763e2dc88d04430dd2524a529eef91a2e517e4e/winsup/cygwin/exec.cc#L111
• OpenBSD 5.9 doesn't support fexecve
• NetBSD doesn't support fexecve, sys_fexecve returns ENOSYS...

According to http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system

#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))

Support for running from memory on macOS works like:

https://github.com/CylanceVulnResearch/osx_runbin/blob/master/run_bin.c

This changes the executable type to MH_BUNDLE, but it uses a number of hardcoded magic strings and I don't know if they're portable across many versions, or if it'd work on iOS