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

Lone_Wolf · 2014-09-06 13:11:47

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.

falconindy · 2014-09-06 14:42:42

Why does the binary format (ELF vs. CLR bytecode) matter? How is this any different from some malicious program compiled by gcc, rustc, 9g, g++, javac, ghc, etc....

Lone_Wolf · 2014-09-06 15:34:54

it's ELF vs MZ binary format .

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.

The /usr/lib/binfmt.d/mono.conf file makes all windows-native MZ-format binaries executable on AL .

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.

Whether the benefit of enabling any non-native executable format outweighs the risk should be decided by the maintainer of a system, NOT by pacman .

In my opinion having /usr/lib/binfmt.d/mono.conf in AL mono package means installing mono decreases the security of my system.

Mono upstream / AL devs / pacman decrease my system security without even NOTIFYING me.

If this thread confirms my feeling that is a bad thing, i'll file a bug report or feature request to ask to change it so mono.conf is disabled by default when installing mono.

falconindy · 2014-09-06 16:11:40

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.

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. The fact that you can't "block" ELF means that ELF is by far a better choice for malware than any other option.

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?

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.Uninstalling mono will cure your fears.

Last edited by falconindy (2014-09-06 16:43:41)

falconindy · 2014-09-06 16:17:28

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).

Last edited by falconindy (2014-09-06 16:38:59)

Lone_Wolf · 2014-09-06 17:10:13

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.

falconindy · 2014-09-09 18:46:42

You seem to have missed the larger point that installing the interpreter is what increases your attack surface. Providing a convenient method of executing these binaries/scripts is simply that -- a matter of convenience.

Installing mono exposes you to attacks via CLR bytecode.
Installing java exposes you to attacks via Java bytecode.
Installing ruby exposes you to attacks via Ruby scripts.

Any sufficiently motivated attacker isn't going to rely on some very optional convenience method to launch their malicious process -- they're going to include or call the interpreter they need with their payload.

Lone_Wolf · 2014-09-13 14:18:42

falconindy,

I agree ALMOST completely with your last post, but it looks like i haven't been clear enough about the problem i see.
Here goes 1 more attempt to clarify :

Archlinux mono package adds a file mono.conf in /usr/lib/binfmt.d/ .
After 1 of these actions :
- user restart systemd-binfmt service
- user reboots system
every file detected as having the MZ magic number in it will be executed by mono .

What you perceive as a "very optional convenience method" is NOT optional on archlinux with mono installed.
Instead of being optional, archlinux mono package enables that behaviour BY DEFAULT .

The solution is simple :
have the mono package install mono.conf into /usr/lib/binfmt.d/examples folder, and it will no longer be enabled by default .

Arch Linux

#1 2014-09-06 13:11:47

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

#2 2014-09-06 14:42:42

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

#3 2014-09-06 15:34:54

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

#4 2014-09-06 16:11:40

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

#5 2014-09-06 16:17:28

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

#6 2014-09-06 17:10:13

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

#7 2014-09-09 18:46:42

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

#8 2014-09-13 14:18:42

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

Board footer