4 ms·

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

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.
- jwilk 8y ago
  > PDFs technically are code PDF is code only in the same sense as HTML is. You can embed JS in PDFs, but that's it. I don't believe Evince supports JS at the moment: https://gitlab.gnome.org/GNOME/evince/issues/24 https://gitlab.gnome.org/GNOME/evince/issues/24
  - dozzie 8y ago
    >> PDFs technically are code > PDF is code only in the same sense as HTML is. Wrong comparison. PDF is code only in the same sense as LaTeX is. PDF is based on PostScript, just as LaTeX is a set of macros on top of TeX, and we all know TeX and PostScript are programming languages and are Turing complete (look for a web server written in PostScript).
    - jwilk 8y ago
      PostScript is indeed a Turing-complete language. It's a common misconception that PDF is an extension of PostScript. PDF is only loosely based on PostScript. In particular, it doesn't support any control flow, like conditions or loops. It is not a programming language, unless you count embedded JavaScript.
badsectoracula 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. However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. I do not see the difference between running `./budget.pdf` and `evince budget.pdf`' - in both cases all the attacker could rely on is a bug in `pdfviewer`. There is no magic going on with `./budget.pdf`, the command would be transformed to the latter.
- gizmo686 8y ago
  The difference is that the attacker can make budget.pdf start with #!/bin/bash and immidietly have arbitrary code execution when I do "./budget.pdf" When I do "evince budget.pdf" the attacker is required to find an exploit of evince.

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.
jwilk 8y ago
> PDFs technically are code PDF is code only in the same sense as HTML is. You can embed JS in PDFs, but that's it. I don't believe Evince supports JS at the moment: https://gitlab.gnome.org/GNOME/evince/issues/24 https://gitlab.gnome.org/GNOME/evince/issues/24
- dozzie 8y ago
  >> PDFs technically are code > PDF is code only in the same sense as HTML is. Wrong comparison. PDF is code only in the same sense as LaTeX is. PDF is based on PostScript, just as LaTeX is a set of macros on top of TeX, and we all know TeX and PostScript are programming languages and are Turing complete (look for a web server written in PostScript).
  - jwilk 8y ago
    PostScript is indeed a Turing-complete language. It's a common misconception that PDF is an extension of PostScript. PDF is only loosely based on PostScript. In particular, it doesn't support any control flow, like conditions or loops. It is not a programming language, unless you count embedded JavaScript.

badsectoracula 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. However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such. I do not see the difference between running `./budget.pdf` and `evince budget.pdf`' - in both cases all the attacker could rely on is a bug in `pdfviewer`. There is no magic going on with `./budget.pdf`, the command would be transformed to the latter.

gizmo686 8y ago
The difference is that the attacker can make budget.pdf start with #!/bin/bash and immidietly have arbitrary code execution when I do "./budget.pdf" When I do "evince budget.pdf" the attacker is required to find an exploit of evince.