In-Memory-Only ELF Execution Without Tmpfs
magisterquis.github.io
In-Memory-Only ELF Execution Without Tmpfs
1–10 of 24 posts
Re: In-Memory-Only ELF Execution Without Tmpfs
#2Oh yeah, I've once discovered this method myself. With execveat() one can even avoid going through procfs.
It doesn't work worth shbang-based scripts, though; that just returns ENOENT. Makes sense, I suppose.
Re: In-Memory-Only ELF Execution Without Tmpfs
#3And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
Re: In-Memory-Only ELF Execution Without Tmpfs
#4And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
Organizing and executing code via a storage scheme other than a file system?
Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs.
Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.
Re: In-Memory-Only ELF Execution Without Tmpfs
#5There are other ways to do this that don't involve tmpfs or write() - see https://github.com/dimkr/papaw and https://github.com/dimkr/Mirai-Source-Code
Re: In-Memory-Only ELF Execution Without Tmpfs
#6And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
Organizing and executing code via a storage scheme other than a file system? Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs. Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.
But a tmpfs (the usual way to do this) isn't persisted to a disk
Re: In-Memory-Only ELF Execution Without Tmpfs
#7And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
In the example given "We've managed to get access to a victim at 10.131.66.89", it's implied that nefariously injecting arbitrary binaries into a locked-down host is one use case.
> otherwise the API would not have been introduced
I don't think memfd_create was added specifically for the purpose of running binaries from memory; it's more generally useful in cases where you want a memory-backed file but don't want to rely on the presence of a memory-backed filesystem (tmpfs). Many programs create a file in a well-known tmpfs like /dev/shm then delete it, but memfd_create is a more sensible solution if you don't want to share memory via the filesystem. memfd_create eliminates concerns over naming and collisions.
Re: In-Memory-Only ELF Execution Without Tmpfs
#8Earlier quoted context omitted.
Organizing and executing code via a storage scheme other than a file system? Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs. Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.
But a tmpfs (the usual way to do this) isn't persisted to a disk
It can be; swap and suspend-to-disk / hibernation can cause tmpfs to be written.
I wonder if there's a way to execute from mlock'd or madvised memory. I can imagine this be particularly useful, if you wanted to prevent your injected program (malware? valuable IP?) from being written to disk or appearing in a core dump.
Re: In-Memory-Only ELF Execution Without Tmpfs
#9And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
Runc used by Docker actually does this. The reason is that you don't want /proc/self/exe to refer to any host path when spawning the container process (see https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...). The way to fix this is to reexecute the runc binary through a memfd so that /proc/self/exe is that memfd.
Re: In-Memory-Only ELF Execution Without Tmpfs
#10Oh yeah, I've once discovered this method myself. With execveat() one can even avoid going through procfs. It doesn't work worth shbang-based scripts, though; that just returns ENOENT. Makes sense, I suppose.
There's also fexecve().