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.
If you're on the terminal and do ./vegas.jpeg though... it's your own fault :P
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.
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
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.
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:
> 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).
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.
That's not really relevant to the concern being raised, though. Although implied, the real concern is running code that has the same system access as your typical executable. That means opening arbitrary files or executing arbitrary executables. I doubt a PDF can do that.
> 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.
This also misses the point. The concern is not that evince will be called, but that it trains the user be less explicit about what he/she wants to do, and that this could cause the system to, at some point, imply the user's intention wrong.
If the first bytes of a file called, `./budget.pdf`, are "#!/bin/bash", the user is most probably going to expect running his trusted evince executable to run pdf code that he/she doesn't need to put particular trust on because the PDF reader will keep it completely restricted from accessing other OS interfaces. What actually will happen, though, is that it's going execute code that has access to everything the user has access to.
We know that this is similar to how scripts are treated, but we don't want that. We need to put way different amounts of trust between data and code files, and having the way we express opening a file differ from running a file expresses that difference of trust to the system.
>> 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.
You can't have your cake and eat it too. :) I'm not even sure if you're really refuting gizmo686's point here. The discussion in this thread is about the potential use of binfmt_misc to open up data files. Because binfmt_misc requires it, it's a given that the executable bit will be set, because this leads us to extend the meaning of "executing" something to opening up data files. I mean "[executing] a pdf"? This would also lead to "executing" png, jpg, zip, mp4, etc. If use of binfmt_misc for this becomes widespread, the executable bit will hardly protect a thing anymore.
However I do take your point that if for some bizarre reason Ubuntu and derivatives did start configuring binfmt_misc to open documents and recommending users getting into the habit of setting the executable bit on docs, that would be a bad thing.
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.
When I do "evince budget.pdf" the attacker is required to find an exploit of evince.