Binfmt.d & /usr/lib/binfmt.d/mono.conf - dangerous ?

Question

copied from https://bbs.archlinux.org/viewtopic.php … 8#p1453898 as i felt this issue is better discussed in a separate thread.
Raynman wrote:The mono package provides /usr/lib/binfmt.d/mono.conf. That makes it possible to put the binary in /usr/bin with the executable bit set. I don't see why that would be such a bad idea.
<snip>
Let's look inside /usr/lib/binfmt.d/mono.conf
:CLR:M::MZ::/usr/bin/mono:
the description for conf files in binfmt.d/ folders is in the kernel sources, Documentation/binfmt_misc.txt  .
entries follow this format :name:type:offset:magic:mask:interpreter:flags
applying that to mono.conf :
name = CLR
type = M , shell will use magic numbers to determine executable, not extension
offset = empty, defaults to 0
magic = MZ   that magic number corresponds with windows executables
mask : empty , defaults to 0xff
interpreter = /usr/bin/mono
flags = optional
The effect of using mono.conf is that any file with the executionable bit set and the magic bytes for a windows executable will be executed by mono .
mono is crossplatform and mono executables will run both on windows and linux.
A hypothetical example :
a malevolent person creates a malware program foo using mono , gives it a name that will make people want to download / run it
To make things easier for *nix users, they offer it as a tar.xz, with the executable bit set for foo.exe
linux user downloads and tries to run it.
if /usr/lib/mono.conf was present on that system before last boot, linux will execute foo.exe and the linux system now has malware installed.
incase /usr/lib/binfmt.d/mono.conf is not present (or disabled) , nothing happens.

Answer 1

TL:DR : falconindy has several valid points, but IN MY OPINION the inclusion of /usr/lib/binfmt.d/mono.conf is a security risk.
It should not be enabled by default.
falconindy wrote:
Lone_Wolf wrote:it's ELF vs MZ binary format .
No, it isn't -- the mono compiler doesn't produce machine code. The windows native binary format PE or COFF.  Mono and other C# compilers produce bytecode known as CLR (Common Language Runtime). The MZ magic number you're referring to is in fact a carryover from older DOS binaries, but you aren't going to produce that format from a mono compiler.
I don't know  what type of binaries mono produces,  but if they're not detected by linux as MZ binaries, the supplied mono.conf won't work as intended.
The same goes for PE / COFF / CLR : if they are detected as having the MZ magic number, they will be executed by mono when /usr/lib/binfmt.d/mono.conf is present.
falconindy wrote:
Lone_Wolf wrote:Afaict all those compilers you mention compile to a linux-native ELF-format binary , and we can't block that and still have a working system.
I mentioned javac which is a bytecode compiler.
javac bytecode doesn't appear to be executable by the linux kernel, and the arch java packages don't come with a binfmt.d file .
falconindy wrote:The fact that you can't "block" ELF means that ELF is by far a better choice for malware than any other option.
correct.
falconindy wrote:
Lone_Wolf wrote:In my opinion any file in a binfmt.d/ default folder ( /etc/binfmt.d , /usr/lib/binmft.d , /run/binfmt.d ) that's added by an automatic process enlarges the potential attack surface against *nix systems by a big factor.
You're still avoiding my question. Why is a mono program more suspicious than an ELF binary when ELF is the universal Linux format? Are you simply equating Windows to malware?
i've worked as a windows sysadmin for over 8 years (desktop and server support) , privately helped windows users for 2 decades and had to solve many malware problems.
Well-configured windows systems can be very safe, unfortunately in my experience those are a small minority.
It's defintely possible i overreact wrt windows malware.
falconindy wrote:
Lone_Wolf wrote:Mono upstream / AL devs / pacman decrease my system security without even NOTIFYING me.
So, you're annoyed that you installed Mono, and now Mono programs Just Work™? I'd say that you could just mask the binfmt service, but you make it very clear that you aren't running systemd. You're on your own.
I don't have mono installed, was just worried about a security issue.
As for being part of a very small minority of arch linux users because i prefer another init then systemd :  i'm used to that, arch still has many advantages over all other distros that's why i stay.
binfmt.d doesn't come from systemd, but from the kernel .
It's man page lists a simple solution to override /usr/lib/binfmt.d files, no need to mask anything.
falconindy wrote:Also note that your malicious binary in /usr/bin could just as easily be a shell script which calls "mono /path/to/my/malware" (or replace "mono" with "python", "ruby", or some rogue ld.so).
correct, but those methods don't open up my system to a large number of unknown binaries.