I've recently seen this post discussing and building on research stemming from google's project zero's looks into hacking exit(). It's pretty interesting! The exit function is as ubiquitous as it is hardened. Every program needs to exit, so how libc decides to is important. Bugs form on complex surfaces, and as more things need to be done at exit (like flushing IO and unloading libraries), more complexity is introduced into exiting. However, exit is fairly hardened. Pointer encryption prevents injecting arbitrary addresses into the exit task chain and requires an extremely difficult primitive to achieve: arbitrary read. An arbitrary read is needed not only to calculate libc base but also to leak the TLS xor key required for encrypting pointers. A weaker primitive like libc leak just isn't sufficient like it usually is. As a result, the research made so far from binholic and project zero is, well, not where it could be. Both rely on powerful primitives to write a generalized exploit against exit, which is unfortunate considering how almost every program which uses libc relies on it. The reduction of these primitives would yield an extremely powerful exploit strategy, one that could work on any program utilizing libc's exit regardless of the actual contents of the program. The greatest primitive to overcome is the requirement of leaks. ASLR has been a hacker's worst nightmare, increasing the complexity of exploits several times over. Many smaller exploit chains have two pieces: gain leak, use the leak to get RCE. libc is designed around forcing hackers to get a leak before they can pwn; just take a look at the recent heap updates in 2.33 which is designed to force getting a leak before the heap could be exploited, stomping out potential hacks before they can show up.

Currently, converting an arbitrary write primitive into RCE is a messy process. The good old days of __free_hook are long gone; now you've got to leak the ptr mangling cookie to modify an existing __exit_funcs entry, maybe compute the offset to ld.so to overwrite l_addr and create a fake DT_FINI entry, or perhaps setup special _codecvt and _wide_data structures on hijacked IO objects... I'd just like to specify the function I want to call and its arguments! I want a flexible RCE primitive. I don't want to rely on _IO_cleanup, _dl_fini, or malloc to call my injected code. I want an inherently universal gadget, a gadget I can expect to be called with the most messed up heap bins and broken IO objects. I want to be able to call any function with any set of arguments without needing to stack pivot or pray system is stack aligned. I don't want to satisfy several constraints so one_gadget will work! setcontext32 setcontext32 is a neat method to convert arbitrary write to flexible arbitrary code execution. Roughly, it looks like: write(libc_write_address, flat( p64(0), p64(libc_write_address + 0x218)

Introduction In this write-up, we'll discuss how to go from one byte out-of-bounds write to a complete ROP chain without IO access and no brute force under extremely restrictive seccomp, without ever knowing ASLR base. Attacks on the GNU C library have been wide and thorough. Many of the complex surfaces in the library, such as malloc or IO, have been thoroughly deconstructed and analyzed to be utilized in exploit chains. However, one surface, the runtime loader, is yet to be brought into its full potential. rtld, as it's called, is rich with complexity and interesting gadgets for a variety of reasons. Background Let's go a little more in-depth on rtld. First, the runtime loader is provided by a shared library named ld.so bundled alongside libc.so. If you've ever seen a virtual memory map of a process, it's almost certain you'll see both ld.so and libc.so in there somewhere. The ubiquity of both makes them very valuable targets for exploitation. Another neat fact is libc.so and ld.so are consistently spaced in memory. They'll be at consistent offsets from each other! This is a byproduct of something known as mmap relativity, where pages allocated by mmap are usually adjacent, and if not, always at a relative offset. This will be useful later.