Oh 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.
In-Memory-Only ELF Execution Without Tmpfs
11–20 of 24 posts
Re: In-Memory-Only ELF Execution Without Tmpfs
#12And you can use '$FH->autoflush(1)' instead of the eye-watering 'select((select($FH), $|=1)[0])'
Re: In-Memory-Only ELF Execution Without Tmpfs
#13There 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
The payload executable is extracted to a temporary file. When running as root, this is done by mounting a tmpfs file system and lazily unmounting it before the extraction.
Re: In-Memory-Only ELF Execution Without Tmpfs
#14And 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.
The memfd api has lots of other uses, the fact you can exec is just a byproduct.
Re: In-Memory-Only ELF Execution Without Tmpfs
#15There 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
#16What I mean is:
- to go from a memfd to anonymous memory, you can call mmap(2) on the fd
- to go from anonymous memory to a memfd, you...?
Re: In-Memory-Only ELF Execution Without Tmpfs
#17Given that Linux now has both file descriptors, and process memory-page ranges, pointing to anonymous allocated memory regions, are they interchangeable? What I mean is: - to go from a memfd to anonymous memory, you can call mmap(2) on the fd - to go from anonymous memory to a memfd, you...?
Re: In-Memory-Only ELF Execution Without Tmpfs
#18There 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
But the readme says: The payload executable is extracted to a temporary file. When running as root, this is done by mounting a tmpfs file system and lazily unmounting it before the extraction.
Re: In-Memory-Only ELF Execution Without Tmpfs
#19Earlier quoted context omitted.
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
#20A bit off-topic, but their perl code is buggy. fork() returns undef on error, not -1. And you can use '$FH->autoflush(1)' instead of the eye-watering 'select((select($FH), $|=1)[0])'
From https://metacpan.org/pod/perl5120delta#Other-potentially-inc... :
> Filehandles are now always blessed into IO::File.
> The previous behaviour was to bless Filehandles into FileHandle (an empty proxy class) if it was loaded into memory and otherwise to bless them into IO::Handle.