FYI - Because JAR files are specially formatted ZIP files, you can also prepend a shell script stub to the front of the file. Java reads JAR files and doesn't start processing them until it sees the ZIP magic bytes (PK\x03\x04). So long as your shell script doesn't contain those bytes, you can add whatever you want.
This is about the minimal stub script you can get away with.
#!/bin/bash
exec java -jar $0 "$@"
exit 1
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.
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:
$ uptime
23:19:03 up 133 days 8:27, 1 user, load average: 0.53, 0.51, 0.49
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
Set this one line setting on a nixos system, and it can run foreign binaries. Magic.
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".
DominoTree•2mo ago
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
Twirrim•2mo ago
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.
jeroenhd•2mo ago
I can only imagine the havoc this would wreak on shell scripts that call out to the test/[/[[ binaries on a system.
porridgeraisin•2mo ago
jeroenhd•2mo ago
__david__•2mo ago
porridgeraisin•2mo ago