Why can you register interpreters as non-root and why do these custom interpreters take precedence?
EDIT: Checked on may dated ubuntu laptop, /proc/sys/fs/binfmt_misc/register is root:root owned with --w-------. An important detail that the article omits and that changes this "vulnerability".
Before knowing about binfmt, I always wondered how wine is able is able to execute .exe files directly, i.e. ./prog.exe instead of wine ./prog.exe. Turns out the wine package (at least on Arch) comes with a handler for them and the Arch wiki mentions that you may want to remove it for security reasons.
It can also be used to automatically execute jar files with "java -jar". I don't think arch is set up to do that automatically, but it is fairly easy to do[1].
Traditionally I've seen these adapters primarily used to pass binaries for other architectures to QEMU and similar.
Years ago on FreeBSD I created a "Volkswagen mode" by using the similar `imgact_binmisc` kernel module to register a handler for binaries with the system's native ELF headers. It took a bit of hacking to make it all work with the native architecture, but when it was done, the handler would simply execute the binary, drop its return code, and return 0 instead - effectively making the system think that every command was "successful"
The system failed to boot when I finally got it all working (which was expected) but it was a fun adventure to do something so pointless and silly.
It would be a similarly clever place to maintain persistence and transparently inject bytecode or do other rude things on FreeBSD as well
Why can you register interpreters as non-root and why do these custom interpreters take precedence?
EDIT: Checked on may dated ubuntu laptop, /proc/sys/fs/binfmt_misc/register is root:root owned with --w-------. An important detail that the article omits and that changes this "vulnerability".
You can't. This is a classic example of an "other side of this airtight hatchway"[1] problem.
[1]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Before knowing about binfmt, I always wondered how wine is able is able to execute .exe files directly, i.e. ./prog.exe instead of wine ./prog.exe. Turns out the wine package (at least on Arch) comes with a handler for them and the Arch wiki mentions that you may want to remove it for security reasons.
It can also be used to automatically execute jar files with "java -jar". I don't think arch is set up to do that automatically, but it is fairly easy to do[1].
[1]: https://wiki.archlinux.org/title/Binfmt_misc_for_Java
Traditionally I've seen these adapters primarily used to pass binaries for other architectures to QEMU and similar.
Years ago on FreeBSD I created a "Volkswagen mode" by using the similar `imgact_binmisc` kernel module to register a handler for binaries with the system's native ELF headers. It took a bit of hacking to make it all work with the native architecture, but when it was done, the handler would simply execute the binary, drop its return code, and return 0 instead - effectively making the system think that every command was "successful"
The system failed to boot when I finally got it all working (which was expected) but it was a fun adventure to do something so pointless and silly.
It would be a similarly clever place to maintain persistence and transparently inject bytecode or do other rude things on FreeBSD as well