HardenedBSD July 2023 Status Report

[Shawn Webb]

Hey all,

There was only one notable change in the src repo in July 2023. But first, a
little background info:

A long time ago, I started on a project that makes anonymous remote code
injection and PLT/GOT redireciton techniques over the ptrace boundary easy
in one little consumable API. The end-goal of the tool is to support injection
of shared objects in a completely anonymous manner, and to be able to hijack
PLT/GOT entries to point to their counterpart in the newly-injected shared
object. I started on this work well over a decade ago (it has roots back to
ideas I had in 2003.) The project is aptly named libhijack[0].

One common technique is to rely on shared memory-backed file descriptors,
writing the shared object to the shmfd, lseek(shmfd,0,seek_set), then
fdlopen(shmfd). This causes the RTLD to load the shared object from anonymous
memory. In fact, I've published a PoC[1] that shows this very technique.

I'm currently working on providing shmfd-based anonymous shared object injection
support in libhijack, so it can be performed over the ptrace boundary with a
simple API call. Imagine something like this on a webserver running nginx:

pid_t pid = get_nginx_pid();
const char *path_to_shared_object = "/lib/libpcap.so.8";
InjectSharedObject(pid, path_to_shared_object);

This would cause the target process to create a new shmfd, write the contents of
libpcap.so.8 to it, seek to the beginning, then load it via fdlopen.

I have this mostly implemented, but I'm running into some ptrace oddities.

Where this ties into HardenedBSD's src is: while writing this code, I kept
thinking to myself, how would I defend against this kind of technique? Results
from fstat(2) aren't helpful as there's no way to detect that we're looking at
an anonymous shared memory-backed file descriptor.

However, I noticed that calling fstatfs(2) on the shmfd causes undocumented
behavior: fstatfs(2) will return EINVAL. The underlying code for shared memory
file descriptors doesn't implement a handler for fstatfs(2), causing the syscall
to return EINVAL.

I then added code to the RTLD to check the return value of a call to fstatfs(2)
on the file descriptor passed in when RTLD hardening is enabled. If fstatfs(2)
fails and sets errno to EINVAL, we prohibit loading the object.

This would force an attacker to fully implement what I call a "remote RTLD": an
out-of-process RTLD that loads objects over a boundary (the boundary in this
particular case being ptrace.) The attacker would have to force the application
to call mmap (which libhijack supports), inject into those new mapping (which
libhijack supports), but then perform all the RTLD logic and fixups over the
boundary (which libhijack does not support.)

My hope is that one day, libhijack gains that last little bit. That last little
bit is the most complex bit. That's why I'm going the shmfd route first: to
prove the concept and to flush out a "rough draft" of what's in my head.

HardenedBSD's PaX NOEXEC-inspired strict W^X implementation is effective over
the ptrace boundary, further frustrating the concept of a remote RTLD.

[0]: https://github.com/SoldierX/libhijack
[1]: https://git.hardenedbsd.org/shawn.webb/random-code/-/tree/main/memdlopen

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc