Today I Learned: Binfmt_misc
Posted2 months agoActiveabout 2 months ago
dfir.chTechstory
calmpositive
Debate
40/100
LinuxBinfmt_miscEmulationKernel Modules
Key topics
Linux
Binfmt_misc
Emulation
Kernel Modules
The article introduces binfmt_misc, a Linux kernel feature that allows registering interpreters for arbitrary binary formats, sparking discussion on its uses, security implications, and related experiences.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
27
Day 7
Avg / period
10
Comment distribution30 data points
Loading chart...
Based on 30 loaded comments
Key moments
- 01Story posted
Nov 3, 2025 at 4:49 PM EST
2 months ago
Step 01 - 02First comment
Nov 9, 2025 at 8:18 PM EST
6d after posting
Step 02 - 03Peak activity
27 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 14, 2025 at 7:28 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45804870Type: storyLast synced: 11/20/2025, 5:36:19 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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
I can only imagine the havoc this would wreak on shell scripts that call out to the test/[/[[ binaries on a system.
For something I was building, it enabled me to get a full aarch64 compilation done, with a native toolkit, without having to run a full emulation layer. The time savings of doing it this way vs full emulation were huge. Off the top of my head, emulated it was taking over an hour to do the full build, whereas within a container it was only about 10-15 minutes.
But inside a container (with its own mount namespace) or inside a chroot then the qemu binaries does not necessarily exist. But the binfmt_misc handler will still work in this case because of two features.
1. The kernel will open the qemu binaries in the original mount namespace when the binfmt_misc handler is registered with the F-flag (Fix binary) so the kernel will always have an open file reference to the qemu binary independent of mount namespace.
2. Distributions (at least Debian) ships statically linked qemu binaries so that qemu does not need to load any shared libraries inside the target namespace/chroot.
[1]: https://wiki.archlinux.org/title/Binfmt_misc_for_Java
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".
[1]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
If it didn't require root access... it would be a privilege escalation. I don't think that counts as a strike against it.
> isn't available in containers
Well, you can't apply it inside of (unprivileged) containers, but I think it does at least work as a backdoor inside of containers.
> can be checked for in a single location
Almost all of them can if you know where to look, though? The point here is that nobody checks for this. If I got pwned I would just light the box on fire and start anew but if I had no choice but to try to clean it up I would never guess about binfmt_misc as a way to regain root. It could go undetected for quite a long time, even if the original problem is patched, which could potentially happen without the administrators realizing the box was compromised.
> and doesn't survive a reboot.
Both this and the comment about containers makes me think you're thinking of modern infrastructure where you use containers and mostly-immutable or actually-immutable OS images, but I think this sort of mechanism is pretty squarely aimed at old-school pets-not-cattle infrastructure. I'd love to say all of my infrastructure is "modern" but sometimes modern infrastructure is just a bit overkill, so while I still would just burn everything down, I do have some infrastructure that is "oldschool". In this case, the threat of a reboot is pretty minuscule. Here, I will demonstrate from a real live server:
Of course, I'm not gloating. I've had uptimes counted in years in the past, and I'm sure there are plenty of people here with more impressive uptimes (and probably a lot more unpatched vulnerabilities, lol.)And the reason the uptime is so high is because the server is relatively important but there is no redundancy, so any updates have to be done as online as possible. In my case it's a matter of reducing costs.
If a box gets pwned I feel like you just need to reformat; and in my case I can, because I have backups and a way to reprovision everything again from scratch. I am going to guess, though, that there's literally tons of infrastructure out there where they don't have adequate backups or a way to reprovision the OS image from scratch.
so it does imply it needs root rights
but it's an example of why it's a bad idea to "cleanup" a system from a virus without a full reinstall
it also matters for other reasons, as some ways to gain root are unreliable and don't persist reboot and you don't want to hide that you have root access
This x1000.
> TL;DR: binfmt_misc provides a nifty way (once the attacker has gained root rights on the machine) to create a little backdoor to regain root access when the original access no longer works.
... he/she/it can create an account, install programs, insert kernel drivers, modify the bootloader, compile a new kernel and so on and so forth
I had a build system which was able to cross compile.
And a test system which wasn't able to handle cross compiled/emulated/remote code but needed to run test on cross compiled code.
In the end with binfmt the test system never knew it was running the code with qemu instead of native and "just worked".
Set this one line setting on a nixos system, and it can run foreign binaries. Magic.