Incompatible with MemoryDenyWriteExecute?

[239]

What's the problem (or question)?

Running compressed binaries by a systemd service using MemoryDenyWriteExecute=true gives this:

Aug 29 10:44:56 systemd[4442]: Started test.service.
Aug 29 10:44:56 kernel: upx[168116]: segfault at 7f0f75728000 ip 00007f0f75728000 sp 00007fffeedacd40 error 15 likely on CPU 3 (core 3, socket 0)
Aug 29 10:44:56 kernel: Code: Unable to access opcode bytes at 0x7f0f75727fd6.
Aug 29 10:44:56 systemd[1]: Started Process Core Dump (PID 168117/UID 0).
Aug 29 10:44:56 systemd-coredump[168119]: [🡕] Process 168116 (upx) of user 1000 dumped core.
                                             
                                             Module /home/239/.local/bin/upx without build-id.
                                             Stack trace of thread 168116:
                                             #0  0x00007f0f75728000 n/a (n/a + 0x0)
                                             ELF object binary architecture: AMD x86-64
Aug 29 10:44:56 systemd[4442]: test.service: Main process exited, code=dumped, status=11/SEGV
Aug 29 10:44:56 systemd[4442]: test.service: Failed with result 'core-dump'.

What should have happened?

Same execution as without MemoryDenyWriteExecute.

Do you have an idea for a solution?

I guess this can't be fixed if I am not mistaken:
MemoryDenyWriteExecute

Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable, are prohibited. Specifically, a system call filter is added (or preferably, an equivalent kernel check is enabled with prctl(2)) that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers. This option improves service security, as it makes harder for software exploits to change running code dynamically. However, the protection can be circumvented, if the service can write to a filesystem, which is not mounted with noexec (such as /dev/shm), or it can use memfd_create(). This can be prevented by making such file systems inaccessible to the service (e.g. InaccessiblePaths=/dev/shm) and installing further system call filters (SystemCallFilter=~memfd_create). Note that this feature is fully available on x86-64, and partially on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar. If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.

How can we reproduce the issue?

1. /home/user/.config/systemd/user/test.service

[Service]
# replace with path to a compressed executable
ExecStart=/home/user/.local/bin/upx
MemoryDenyWriteExecute=true
[Install]
WantedBy=default.target

2. systemctl --user daemon-reload
3. systemctl --user enable --now test.service
4. systemctl --user status test.service

Please tell us details about your environment.

• UPX version used (upx --version): 4.1.0
• Host Operating System and version: Linux 6.4.11
• Host CPU architecture: x86-64
• Target Operating System and version: Linux 6.4.11
• Target CPU architecture: x86-64

[jreiser]

In a main program that is compressed by UPX, then the run-time execution stub (the de-compressor) could be changed to use {memfd_create + ftruncate + mmap(,, |PROT_WRITE,|MAP_SHARED,,) + store + munmap() + mmap(,, PROT_EXEC,,,)} instead of mprotect(,,|PROT_EXEC). This has already been done for shared libraries in the current release upx-4.1.0. (See the code in upx/src/stub/src/amd64-linux.elf-so_main.c). So please try such a shared library with a non-compressed main program.

I have no sympathy for an outright ban on JIT (Just In Time) code. Such a ban imposes exorbitant costs in complexity, size, and speed. If memfd_create is banned (and the equivalent using /dev/shm with an explicit filename that is immediately unlink()ed) then UPX cannot work at all.

[239]

Thanks for the detailed clarification! The option is for hardening service units but optional and can be disabled if necessary.
I have to look for a suitable program with shared libraries and test again.

Found this related issue from 2019: MemoryDenyWriteExecute should block memfd_create

[jreiser]

upx-.5.0.0 enables execution in Enforcing mode of SELinux, using the strategy outlined above ( memfd_create, ...).

There is no way that upx-compressed code (or any other JIT app) can work if executable instructions cannot be generated at run time. Taken to the extreme, MemoryDenyWriteExecute prohibits the use of shared libraries, because dlopen() generates "new code" into the address space initialized by execve().