
The real power of Linux executables - janvdberg
https://ownyourbits.com/2018/05/23/the-real-power-of-linux-executables/
======
LinuxBender
Disclaimer: Unpopular opinion ahead.

I am not a fan of binfmt_misc. Please hear me out.. This introduces the same
framework for future vulnerabilities that Microsoft introduced long ago by
having the system interrogate file type associations. This turned into easy
mode for attackers to trick people into executing malicious files on their
system. This has not happened _yet_ in Linux AFAIK, but this sets the
framework for it.

In Windows, you can see this mapping by opening a command prompt and typing:

    
    
        assoc
    

It was common practice for some time to change VBS mapping to text, along with
several other file types.

In my opinion, we are bringing a dangerous behavior into systems that could
one day be commonly used as desktops.

~~~
laumars
Interesting point - one I hadn't considered. While I'm not trying to discount
your valid concerns, Linux does have one other thing in it's favour and that
is that files still need an executable bit to be set in order for binfmt_misc
to even get called. Whereas on Windows the only requirement for something to
be executable is the file extension to have an association with an
interpreter. So on Linux you wouldn't have the same default behaviour because
that executable bit isn't set by default.

Moreover, if you can get around that executable bit problem then you're no
worse of with binfmt_misc than you would be without since you could
legitimately create a text file called "cat.jpg" with a Bash shebang and that
would launch Bash in the same was a somescript.sh might.

Of course, you could take things one step further and say if a malicious actor
has access to your system then they might get around the execution bit problem
by just calling the interpreter directly (eg "bash somescript.sh" or the
/lib64/ld-linux-x86-64.so.2 /bin/sleep 30 example in the article). But that
requires the actor has remote code execution rights rather than just
permissions to write to the file system. And honestly by that point you've
already lost the game anyway.

~~~
amluto
It’s not just the X bit —- unixes also don’t implicitly put the current
directory in the path.

~~~
laumars
I'm curious what advantages that brings for security since executables can
still be called via relative (./) and absolute paths.

The biggest advantage that immediately springs to mind is writable directories
included in PATH but even there some Linux distributions do include ~/bin in
their users PATH. Thankfully PATH is an order of precidence and ~/bin comes
last negating the ability for a script in ~/bin from "overwriting" /usr/bin/
et al. (ie `~/bin/sed` wouldn't become the default sed). I believe in Windows
- though I'm not in a position to check - also places the working directory as
last precidence when checking for instances in PATH.

There maybe some other vulnerability I am completely unaware of though but
that's what I've experienced when messing around with Windows

~~~
jupp0r
It's presumably easier for an attacker to get a malicious ls binary into some
local directory and convince a privileged user to execute ls there than
putting a malicious ls binary into /usr/bin.

~~~
laumars
Yeah, I already covered that point re writable directories in PATH (though
maybe I wasn't all that clear?). But in your specific case you need the
additional process of getting the privileged user to change to that directory
as well and for there to be no executables with the same name in another
directory in PATH with a higher precidence. By which point it's easier to just
getting said administrator to just run an executable via its absolute path
rather than social engineering it into PATH

------
Aissen
binfmt_misc is awesome. Little known fact: on most distros, you can combine
the power of binfmt and qemu to run binaries from another architecture: either
in a chroot/container or directly in debian:

[https://wiki.debian.org/QemuUserEmulation](https://wiki.debian.org/QemuUserEmulation)

[https://npmccallum.gitlab.io/post/cross-architecture-
roots-w...](https://npmccallum.gitlab.io/post/cross-architecture-roots-with-
dnf/)

This allows you to test your rasberry pi images/binaries directly on your x86
machine (and vice-versa), for example.

~~~
aurelian15
I was once extremely confused by this black magic. For some reason, the
binaries that I cross-compiled for an embedded ARM system ran on the host
system! I forgot that I installed Qemu a while ago, and someone at Stack
Overflow had to point me at binfmt_misc [1]

[1] [https://stackoverflow.com/questions/37912290/arm-linux-
execu...](https://stackoverflow.com/questions/37912290/arm-linux-executable-
mysteriously-runs-on-x86-64)

------
haberman
I experimented recently with writing a user-space ELF loader. Why should ELF
loading need to happen in the kernel? Ok, there are _some_ good reasons (the
kernel has an easier time of single-handedly cleaning up all file descriptors,
memory mappings, etc. in one fell swoop inside execve(). Are there others?).
But I think it's an interesting proof-of-concept to show that ELF loading from
user-space is totally possible.

When I started down this path, I learned some interesting details of the
kernel/userspace interface that I wasn't aware of before, like the ELF
Auxiliary Vector, which is how the kernel communicates some basic information
to the process, like its arguments and uid/gid.

[https://lwn.net/Articles/519085/](https://lwn.net/Articles/519085/)

~~~
xenadu02
> the kernel has an easier time of single-handedly cleaning up all file
> descriptors, memory mappings, etc. in one fell swoop inside execve()

fork() / execve() isn't a good mechanism for launching new processes; it's one
of the worst aspects of early Unix design.

A properly designed syscall should require the caller to specify the desired
behavior explicitly:

1\. Do I want to inherit file descriptors, etc or do I want a clean slate? 2\.
Do I want a separate address space or to share address space? 3\. What happens
to threads, mutexes, locks, etc in the new child process? 4\. If a separate
address space should I inherit my parent's VM mappings or should I just load
and execute a new binary image?

That gives flexibility to the caller and maximum information to the kernel to
optimize. Instead we have a bunch of ad-hoc patches like vfork(), clone(), and
posix_spawn() (+ non-standard attributes like POSIX_SPAWN_CLOEXEC_DEFAULT,
POSIX_SPAWN_SETEXEC, and POSIX_SPAWN_USEVFORK).

------
jacob019
Like the author, I'm sure many of us imagined that the shell was inspecting
our scripts and calling the interpreter. Good to know it happens in the
kernel.

I wonder why more packages don't register handlers. It would be cool if simply
installing dosbox made exe's executable.

~~~
jacobush
Someone else thought that too [https://www.linux.com/news/how-launch-windows-
binaries-linux...](https://www.linux.com/news/how-launch-windows-binaries-
linux-directly) :-)

------
jstarks
Yes, bitfmt_misc is quite useful. In WSL (Windows Subsystem for Linux), we
register Windows executables in binfmt_misc and have a handler that launches a
Windows process back and relays stdin, etc.:

    
    
        $ cat /proc/sys/fs/binfmt_misc/WSLInterop
        enabled
        interpreter /init
        flags:
        offset 0
        magic 4d5a
    

This is nice because it uses standard Linux functionality; we didn't have to
extend our Linux-compatible kernel interface to support running Windows
processes.

------
AndrewOMartin
I'm not usually that excitable about these kind of feature demonstrations, but
when I first made an old DOS game execute from my Linux terminal I did
something reminiscent of Lucille Bluth spotting Gene Parmesan.

------
jeffreyrogers
This is a good write-up. I remember reading through the kernel source code
trying to understand this a few months ago because I was curious about what it
would take to add binary whitelisting to the kernel. The Linux source code is
not too hard to understand (if you have some background in how OS's work and
know C). Especially if you have a topic that you want to know about.

------
DyslexicAtheist
my fav ELF binaries document / howto is Alexander Bartolich's (RiP) Virus
writing howto:
[http://www.linuxsecurity.com/resource_files/documentation/vi...](http://www.linuxsecurity.com/resource_files/documentation/virus-
writing-HOWTO/_html/index.html)

------
cphuntington97
If this article is a little over my head, what can I read that will help me
understand?

~~~
cache_miss
If the kernel parts are confusing you, I highly recommend "Linux Kernel
Development" by Robert Love as a high-level introduction to the kernel
architecture.

If you like that, proceed to "Linux Kernel Architecture" by Wolfgang Mauerer.
The first chapter contains information similar to this article, but at a much
greater level of detail.

~~~
cphuntington97
Have you read Operating Systems: Design and Implementation?

~~~
cache_miss
I haven't, but I've been meaning to read at least one of his books.

------
michaelmcmillan
binfmt_misc is rad!

------
nameiscubanpete
I come to this site for articles like this.

------
dddw
sorcery!

