20 ms·

The real power of Linux executables

346 points by janvdberg 8y ago

jacob019 8y ago
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 8y ago
  Someone else thought that too https://www.linux.com/news/how-launch-windows-binaries-linux-directly https://www.linux.com/news/how-launch-windows-binaries-linux... :-)
- seiferteric 8y ago
  When you install Wine, it does happen that way.
- BlackLotus89 8y ago
  I did this a few years ago. I find it kind oft annoying to be honest since I use many wine prefixes and don't usually want to execute Windows applications that way. Don't know it's just a preferance.
Aissen 8y ago
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-with-dnf/ https://npmccallum.gitlab.io/post/cross-architecture-roots-w... This allows you to test your rasberry pi images/binaries directly on your x86 machine (and vice-versa), for example.
- aurelian15 8y ago
  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-executable-mysteriously-runs-on-x86-64 https://stackoverflow.com/questions/37912290/arm-linux-execu...
DyslexicAtheist 8y ago
my fav ELF binaries document / howto is Alexander Bartolich's (RiP) Virus writing howto: http://www.linuxsecurity.com/resource_files/documentation/virus-writing-HOWTO/_html/index.html http://www.linuxsecurity.com/resource_files/documentation/vi...
michaelmcmillan 8y ago
binfmt_misc is rad!
cphuntington97 8y ago
If this article is a little over my head, what can I read that will help me understand?
- mkirklions 8y ago
  Do you program for linux much? If you dont, you can probably skip this article for now. The article was somewhat interesting, but since my current app is react native javascript, its really disconnected from application. You wouldnt be playing around at these linux system levels, you likely will be developing using linux as a platform.
- laumars 8y ago
  All of it or are there any specific parts you want clarification on?
  - cphuntington97 8y ago
    I read Code by Charles Petzold so I think I have at least some concept of how the operating system and hardware communicate. So now I guess I need a better understanding of how applications communicate with the operating system, as recommended by another reply, more for the sake of knowing rather than any practical reason.
    - exikyut 8y ago
      I'm not sure if you'll see this late reply, but here's an idea that may be interesting (ie, accessible and hopefully not too challenging): write a Linux program that doesn't link a standard library (aka glibc). The result will be something that only uses kernel syscalls. Your first such program probably wouldn't do much; low expectations would be ideal. Returning an arbitrary exit code could be one startpoint, or printing a fixed string could work too (you have write() to write bytes to the TTY, but not printf() (and %s, %d, etc!), as that's a stdlib function :D). This would be a "journey" exercise, not an "end goal" exercise. You'll need to learn how to - Disable linking the C runtime (crt0 et al - compile a .c file with 'gcc -v' and pour over the output and you'll spot several crt* things at the link stage), which will mean learning about '-nostdlib', '-nostartfiles' and related parameters - Deal with the fact that you don't have a main() anymore, you're expected to define _start() instead - Rummage through a standard library to figure out how to do, well, anything - I recommend poking a smaller C library, like musl or klibc, for ideas (it's mostly boring drudgery you won't need to extensively follow up on just to get started; and there are sufficient "I'm making a tiny stdlib!" projects floating around github that it may be a good idea to weigh up making a 6,983rd - that said, by all means take the opportunity to implement your own strlen(), things like that they're standard entry-level whiteboard challenges) A good way to get your feet wet might be to first link with musl/klibc/similar, so you can get an idea of the fragility at play (mostly compilers' faults) without blowing everything up instantly, so you can learn how "actually don't use glibc please" is handled in practice. (Read: gcc works, but only within a very narrowly defined scope; clang may work, but may not have as much (easily-found) documentation as gcc. The IRC channel/mailinglist will probably be useful if you're sufficiently interested, but the responses you get may take a day to understand/unpack :) ) There's just enough documentation floating around on stackoverflow and related places that the process isn't overly terrible to start with, and this particular learning process will very clearly explain a heap of stuff. If you like I can try digging out a bunch of links, but it might take a while (my bookmarks are a thoroughly under-categorized tangle :( ).
dddw 8y ago
sorcery!
- mlvljr 8y ago
  treachery!
AndrewOMartin 8y ago
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.
LinuxBender 8y ago
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.
- jxy 8y ago
  I was wondering why no one finds it scary in terms of security and integrity of the system.
- jwilk 8y ago
  "Modern" desktop environments of course do have file type associations, but this is unrelated to binfmt_misc. I can't think of any realistic threat model in which binfmt_misc would reduce security. If you are running untrusted code, it doesn't matter it's an ELF, a shell script, or a VBS script ran through Wine. It's game over anyway.
  - peterwwillis 8y ago
    You don't know if you're running any code at all. You double click on a .jpeg file, and suddenly a python script is running. There are many ways to trick systems and users into running something when they didn't want to run anything, but binfmt_misc makes this easier for the attacker.
    - Spivak 8y ago
      We're talking about a very specific situation where the attacker has enough privilege to add an association but not enough privilege to just run the malicious program.
jeffreyrogers 8y ago
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.
haberman 8y ago
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/
- gizmo686 8y ago
  Not nearly an ELF loader, but during my security class, I wanted to test my payloads, so I wrote a load_bin program which read a file into a buffer, then jmp`ed to the start of the buffer.
- deleted 8y ago
  [deleted]
- xenadu02 8y ago
  > 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).
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
jstarks 8y ago
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.
nameiscubanpete 8y ago
I come to this site for articles like this.

346 points by janvdberg 8y ago

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 8y ago
Someone else thought that too https://www.linux.com/news/how-launch-windows-binaries-linux-directly https://www.linux.com/news/how-launch-windows-binaries-linux... :-)
seiferteric 8y ago
When you install Wine, it does happen that way.
BlackLotus89 8y ago
I did this a few years ago. I find it kind oft annoying to be honest since I use many wine prefixes and don't usually want to execute Windows applications that way. Don't know it's just a preferance.

Aissen 8y ago

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-with-dnf/ https://npmccallum.gitlab.io/post/cross-architecture-roots-w... This allows you to test your rasberry pi images/binaries directly on your x86 machine (and vice-versa), for example.

aurelian15 8y ago
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-executable-mysteriously-runs-on-x86-64 https://stackoverflow.com/questions/37912290/arm-linux-execu...

DyslexicAtheist 8y ago

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

michaelmcmillan 8y ago

binfmt_misc is rad!

cphuntington97 8y ago

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

mkirklions 8y ago
Do you program for linux much? If you dont, you can probably skip this article for now. The article was somewhat interesting, but since my current app is react native javascript, its really disconnected from application. You wouldnt be playing around at these linux system levels, you likely will be developing using linux as a platform.
laumars 8y ago
All of it or are there any specific parts you want clarification on?
- cphuntington97 8y ago
  I read Code by Charles Petzold so I think I have at least some concept of how the operating system and hardware communicate. So now I guess I need a better understanding of how applications communicate with the operating system, as recommended by another reply, more for the sake of knowing rather than any practical reason.
  - exikyut 8y ago
    I'm not sure if you'll see this late reply, but here's an idea that may be interesting (ie, accessible and hopefully not too challenging): write a Linux program that doesn't link a standard library (aka glibc). The result will be something that only uses kernel syscalls. Your first such program probably wouldn't do much; low expectations would be ideal. Returning an arbitrary exit code could be one startpoint, or printing a fixed string could work too (you have write() to write bytes to the TTY, but not printf() (and %s, %d, etc!), as that's a stdlib function :D). This would be a "journey" exercise, not an "end goal" exercise. You'll need to learn how to - Disable linking the C runtime (crt0 et al - compile a .c file with 'gcc -v' and pour over the output and you'll spot several crt* things at the link stage), which will mean learning about '-nostdlib', '-nostartfiles' and related parameters - Deal with the fact that you don't have a main() anymore, you're expected to define _start() instead - Rummage through a standard library to figure out how to do, well, anything - I recommend poking a smaller C library, like musl or klibc, for ideas (it's mostly boring drudgery you won't need to extensively follow up on just to get started; and there are sufficient "I'm making a tiny stdlib!" projects floating around github that it may be a good idea to weigh up making a 6,983rd - that said, by all means take the opportunity to implement your own strlen(), things like that they're standard entry-level whiteboard challenges) A good way to get your feet wet might be to first link with musl/klibc/similar, so you can get an idea of the fragility at play (mostly compilers' faults) without blowing everything up instantly, so you can learn how "actually don't use glibc please" is handled in practice. (Read: gcc works, but only within a very narrowly defined scope; clang may work, but may not have as much (easily-found) documentation as gcc. The IRC channel/mailinglist will probably be useful if you're sufficiently interested, but the responses you get may take a day to understand/unpack :) ) There's just enough documentation floating around on stackoverflow and related places that the process isn't overly terrible to start with, and this particular learning process will very clearly explain a heap of stuff. If you like I can try digging out a bunch of links, but it might take a while (my bookmarks are a thoroughly under-categorized tangle :( ).

dddw 8y ago

sorcery!

mlvljr 8y ago
treachery!

AndrewOMartin 8y ago

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.

LinuxBender 8y ago

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.

jxy 8y ago
I was wondering why no one finds it scary in terms of security and integrity of the system.
jwilk 8y ago
"Modern" desktop environments of course do have file type associations, but this is unrelated to binfmt_misc. I can't think of any realistic threat model in which binfmt_misc would reduce security. If you are running untrusted code, it doesn't matter it's an ELF, a shell script, or a VBS script ran through Wine. It's game over anyway.
- peterwwillis 8y ago
  You don't know if you're running any code at all. You double click on a .jpeg file, and suddenly a python script is running. There are many ways to trick systems and users into running something when they didn't want to run anything, but binfmt_misc makes this easier for the attacker.
  - Spivak 8y ago
    We're talking about a very specific situation where the attacker has enough privilege to add an association but not enough privilege to just run the malicious program.

jeffreyrogers 8y ago

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.

haberman 8y ago

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/

gizmo686 8y ago
Not nearly an ELF loader, but during my security class, I wanted to test my payloads, so I wrote a load_bin program which read a file into a buffer, then jmp`ed to the start of the buffer.
deleted 8y ago
[deleted]
xenadu02 8y ago
> 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).

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

jstarks 8y ago

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.

nameiscubanpete 8y ago

I come to this site for articles like this.