4 ms·

"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 wh

by 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.
- chungy 8y ago
  Doesn't actually happen though. GUI file managers prompt whether you want to execute a script or display it in a text editor. If you're on the terminal and do ./vegas.jpeg though... it's your own fault :P
- beojan 8y ago
  Generally the file managers on Linux use "magic" to determine file type rather than extensions, so even if it would run you should know it's really a Python script.
gizmo686 8y ago
The point is that binfmt_misc could allow you to run unstrusted code in a context where you were not expecting to run any code. For instance, if I do "./budget.pdf", I expect it to run the code from my pdf reader. In this case, an attack would require exploiting a vulnerability in the pdf reader. That is to say, budget.pdf is not untrusted code, but rather untrusted data. However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. In contrast, when I do `evince budget.pdf`, the only way for budget.pdf to become code is to trick the pdf reader into thinking it is code. Granted, this is largely a moot point as most people would be using a GUI file manager; which already has a common interface for running programs and opening data files; and already automatically determines which action to take.
- laumars 8y ago
  > For instance, if I do "./budget.pdf", I expect it to run the code from my pdf reader. In this case, an attack would require exploiting a vulnerability in the pdf reader. That is to say, budget.pdf is not untrusted code, but rather untrusted data. You cannot simply do ./budget.pdf. If you don't have the executable bit set you'd get a permission denied error (since that file doesn't have permission to execute). And even if you did have the execution bit set, it would fail because there isn't an interpreter configured to execute a pdf (which is the point of binfmt_misc in this context). The executable bit is what Linux / UNIX / et al use to set whether something is executable code or not. Not the file extension (like in Windows). > However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. Not without setting the executable bit first. (eg chmod +x budget.pdf) > In contrast, when I do `evince budget.pdf`, the only way for budget.pdf to become code is to trick the pdf reader into thinking it is code. Two points: 1/ PDFs technically are code though. They're Turing complete. 2/ running `evince budget.pdf` is exactly the same as running `./budget.pdf` where PDF's are mapped to evince via binfmt_misc. Just as running `./my-script.sh` is literally the same as running `/bin/sh ./my-script.sh` (where the shebang is /bin/sh). So your example and counter-example are actually the same process getting called by the kernel. It's the same thing with binaries that don't have a shebang, such as ELFs. There is a magic header (which the article mentions so I wont reiterate that) and if the binary is identified as an ELF binary so the kernel runs it by calling the ld loader, eg: /lib64/ld-linux-x86-64.so.2 /bin/sleep 10 (you can actually run this yourself from Bash too)
  - bartc 8y ago
    Yes, but unfortunately the executable bit would be preserved if the file was delivered by way of a .tar.gz bundle. A reasonable user expectation would be to double-click on the .tar.gz to unravel it and then double click on the pdf to open it.
    - laumars 8y ago
      But again, the PDF would just open with the same program it would have regardless of whether it's called via binfmt_misc or not. Besides, a much easier vector for attack in your example would be to create a shell script called "budget.pdf" since you then need to make fewer assumptions about the target. And since Linux doesn't care about file extensions, it's perfectly fine having a shebang prefixed script with a .pdf extension. Which is one of many reasons why common advise is not to blindly run any executables you've just imported into your system.

by jwilk 8y ago

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.
chungy 8y ago
Doesn't actually happen though. GUI file managers prompt whether you want to execute a script or display it in a text editor. If you're on the terminal and do ./vegas.jpeg though... it's your own fault :P
beojan 8y ago
Generally the file managers on Linux use "magic" to determine file type rather than extensions, so even if it would run you should know it's really a Python script.

gizmo686 8y ago

The point is that binfmt_misc could allow you to run unstrusted code in a context where you were not expecting to run any code. For instance, if I do "./budget.pdf", I expect it to run the code from my pdf reader. In this case, an attack would require exploiting a vulnerability in the pdf reader. That is to say, budget.pdf is not untrusted code, but rather untrusted data. However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. In contrast, when I do `evince budget.pdf`, the only way for budget.pdf to become code is to trick the pdf reader into thinking it is code. Granted, this is largely a moot point as most people would be using a GUI file manager; which already has a common interface for running programs and opening data files; and already automatically determines which action to take.

laumars 8y ago
> For instance, if I do "./budget.pdf", I expect it to run the code from my pdf reader. In this case, an attack would require exploiting a vulnerability in the pdf reader. That is to say, budget.pdf is not untrusted code, but rather untrusted data. You cannot simply do ./budget.pdf. If you don't have the executable bit set you'd get a permission denied error (since that file doesn't have permission to execute). And even if you did have the execution bit set, it would fail because there isn't an interpreter configured to execute a pdf (which is the point of binfmt_misc in this context). The executable bit is what Linux / UNIX / et al use to set whether something is executable code or not. Not the file extension (like in Windows). > However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. Not without setting the executable bit first. (eg chmod +x budget.pdf) > In contrast, when I do `evince budget.pdf`, the only way for budget.pdf to become code is to trick the pdf reader into thinking it is code. Two points: 1/ PDFs technically are code though. They're Turing complete. 2/ running `evince budget.pdf` is exactly the same as running `./budget.pdf` where PDF's are mapped to evince via binfmt_misc. Just as running `./my-script.sh` is literally the same as running `/bin/sh ./my-script.sh` (where the shebang is /bin/sh). So your example and counter-example are actually the same process getting called by the kernel. It's the same thing with binaries that don't have a shebang, such as ELFs. There is a magic header (which the article mentions so I wont reiterate that) and if the binary is identified as an ELF binary so the kernel runs it by calling the ld loader, eg: /lib64/ld-linux-x86-64.so.2 /bin/sleep 10 (you can actually run this yourself from Bash too)
- bartc 8y ago
  Yes, but unfortunately the executable bit would be preserved if the file was delivered by way of a .tar.gz bundle. A reasonable user expectation would be to double-click on the .tar.gz to unravel it and then double click on the pdf to open it.
  - laumars 8y ago
    But again, the PDF would just open with the same program it would have regardless of whether it's called via binfmt_misc or not. Besides, a much easier vector for attack in your example would be to create a shell script called "budget.pdf" since you then need to make fewer assumptions about the target. And since Linux doesn't care about file extensions, it's perfectly fine having a shebang prefixed script with a .pdf extension. Which is one of many reasons why common advise is not to blindly run any executables you've just imported into your system.