What's of greater importance here is not this specific security issue, but the default configuration of MIME handling in Emacs which can turn any unexpected evaluation bug -which we are likely to see more of- into remote code execution. We've had a previous Org security issue in exactly the same vein [1] and the Emacs MIME defaults are still unsafe. Of course, one can change them (non-trivial and related documentation is extremely confusing, see [2] for a possible solution) but really Emacs should not come with these defaults.
The loss of on-by-default functionality such as Org fontification in email message buffers is in no way as important as being wide open to trivial remote code execution.
I don’t fully understand lisp nor emacs internals. Do you anticipate similar bugs would exist across different major and minor modes, or emacs by default?
E.g., is markdown-mode or python-mode likely to have similar bugs? What about web browser modes, or chat modes, etc?
I genuinely like emacs but I’m worried for a future where my client cannot be trusted to not evaluate random data it has in files.
These bugs can be described as the major or minor mode evaluating code that is provided as part of the buffer that the mode is being enabled for. The two semi-recent examples that come to mind include Org (which offers this code evaluation as a feature) and text/enriched (which allowed arbitrary Lisp evaluation through a non-standard extension). In both of these cases, the evaluation was -somewhat- intended and even documented, so these are not bugs in the traditional definition. They become security bugs when one takes into account the exposed attack surface / dynamic interaction with parts of Emacs automatically switching on the mode (e.g. through an email in Gnus) on 3rd party untrusted input.
I don't expect to see code evaluation on untrusted input as intended features in web browser or chat modes.
> I don't expect to see code evaluation on untrusted input as intended features in web browser
I'm not sure whether to laugh or cry at that. Suffice to say that ship has sailed all the way around the world several times, to the great detriment of everyone who isn't a advertising or other malware-development corporation.
But surely someone out there will make a code highlighter for EWW, and maybe that highlighter calls org-mode on some block and that ends up evaluating stuff etc.
Most recent Office configurations don't trust any downloaded documents, and most recent email configurations have forced me to send code snippets as .txt or some denuded variation.
But expected evaluation is a feature, and not everyone wants to inject a permissions system that gets in the way every time you open a document. Not everything is a web browser that needs to run arbitrary code from arbitrarily bad actors.
A warning and a prompt would largely be useless in this case anyway. As soon as you'd click the prompt, the evil code would run. What you'd need is an option set in your init file to allow code to execute on opening only if a particular piece of information known only to you is included in the file, like #+runcode: a19ihlkn01nf2n9882n4337974biskjf
Sure, I agree with that behavior assuming the user wants the security. If the user wants to disable it, they should be able to do so. It's awful to assume users can't make the decision for themselves.
To be clear, this bug is about arbitrary code execution on another machine as soon as a user on that machine opens an email with Emacs that has a malicious org atrachment. It is not about the user opening one of their own files and the user has no chance to preview the code before executing it. So it is a perfect remote takeover of any machine that happens to use a default Emacs for email.
Codewise I'd prefer a signaled error in elisp and something like your proposed magic/back-door as a handler you'd have to set up in user(-config) space.
As far as I can tell, Emacs prompts you every time it evaluates code when opening a file, and so does Org Babel. This can be turned off but you need to do it explicitly.
Following ‘shell’ and ‘elisp’ links
Org has two link types that can directly evaluate code (see External Links). Because such code is not visible, these links have a potential risk. Org therefore prompts the user when it encounters such links. The customization variables are:
User Option: org-link-shell-confirm-function
Function that prompts the user before executing a shell link.
User Option: org-link-elisp-confirm-function
Function that prompts the user before executing an Emacs Lisp link.
What's of greater importance here is not this specific security issue, but the default configuration of MIME handling in Emacs which can turn any unexpected evaluation bug -which we are likely to see more of- into remote code execution. We've had a previous Org security issue in exactly the same vein [1] and the Emacs MIME defaults are still unsafe. Of course, one can change them (non-trivial and related documentation is extremely confusing, see [2] for a possible solution) but really Emacs should not come with these defaults.
The loss of on-by-default functionality such as Org fontification in email message buffers is in no way as important as being wide open to trivial remote code execution.
[1] https://github.com/emacs-mirror/emacs/commit/befa9fcaae29a6c...
[2] https://xristos.sdf.org/fix-gnus-mime.el.txt
I don’t fully understand lisp nor emacs internals. Do you anticipate similar bugs would exist across different major and minor modes, or emacs by default?
E.g., is markdown-mode or python-mode likely to have similar bugs? What about web browser modes, or chat modes, etc?
I genuinely like emacs but I’m worried for a future where my client cannot be trusted to not evaluate random data it has in files.
These bugs can be described as the major or minor mode evaluating code that is provided as part of the buffer that the mode is being enabled for. The two semi-recent examples that come to mind include Org (which offers this code evaluation as a feature) and text/enriched (which allowed arbitrary Lisp evaluation through a non-standard extension). In both of these cases, the evaluation was -somewhat- intended and even documented, so these are not bugs in the traditional definition. They become security bugs when one takes into account the exposed attack surface / dynamic interaction with parts of Emacs automatically switching on the mode (e.g. through an email in Gnus) on 3rd party untrusted input.
I don't expect to see code evaluation on untrusted input as intended features in web browser or chat modes.
> I don't expect to see code evaluation on untrusted input as intended features in web browser
I'm not sure whether to laugh or cry at that. Suffice to say that ship has sailed all the way around the world several times, to the great detriment of everyone who isn't a advertising or other malware-development corporation.
There's no JS interpreter in EWW [1]. If you're forced to use a different browser, having JS off by default is not hard to get used to.
[1] https://www.gnu.org/software/emacs/manual/html_node/eww/Over...
But surely someone out there will make a code highlighter for EWW, and maybe that highlighter calls org-mode on some block and that ends up evaluating stuff etc.
The vulnerability is that Emacs evaluates this automatically:
#+LINK: shell %(shell-command-to-string) [[shell:touch ~/hacked.txt]]
Is that only if the file has a specific extension? I'm not seeing it with a .txt extension.
You need to have OrgMode active, which is usually not enabled for .txt. Try .org as the extension, or run `M-x org-mode` after opening the file.
I thought it’s feature. Org mode file can be used as a runable document. You have paragraphs of text and then a section containing executable code.
Yes, but that is not what the linked vulnerability is about.
https://orgmode.org/worg/org-contrib/babel/intro.html
It is, similarly to how Microsoft Office documents can run legitimate/malicious executable code.
Although, Office (and most other software) will at least warn you before executing code/malware in such documents originating from the Internet.
Most recent Office configurations don't trust any downloaded documents, and most recent email configurations have forced me to send code snippets as .txt or some denuded variation.
Code snippets as text is denuded but word documents are good for code... what universe is this?
Word vs. Outlook
Unexpected evaluation is never a feature, Emacs should at least warn and prompt before executing code in a file that somebody opens.
But expected evaluation is a feature, and not everyone wants to inject a permissions system that gets in the way every time you open a document. Not everything is a web browser that needs to run arbitrary code from arbitrarily bad actors.
A warning and a prompt would largely be useless in this case anyway. As soon as you'd click the prompt, the evil code would run. What you'd need is an option set in your init file to allow code to execute on opening only if a particular piece of information known only to you is included in the file, like #+runcode: a19ihlkn01nf2n9882n4337974biskjf
Emacs already restricts what variables can be set as file-local. It will prompt you to ask what to do if you open a file containing:
any mode associated with a file extension should be at least as secure against code execution.Sure, I agree with that behavior assuming the user wants the security. If the user wants to disable it, they should be able to do so. It's awful to assume users can't make the decision for themselves.
To be clear, this bug is about arbitrary code execution on another machine as soon as a user on that machine opens an email with Emacs that has a malicious org atrachment. It is not about the user opening one of their own files and the user has no chance to preview the code before executing it. So it is a perfect remote takeover of any machine that happens to use a default Emacs for email.
Codewise I'd prefer a signaled error in elisp and something like your proposed magic/back-door as a handler you'd have to set up in user(-config) space.
I am on the camp that agrees with that, but there are many who don't :/
As far as I can tell, Emacs prompts you every time it evaluates code when opening a file, and so does Org Babel. This can be turned off but you need to do it explicitly.
might be good if it's not "auto run", but otherwise running code inside org-mode is definitely part of the appeal.
Clearly, if you care about security here, the best thing is to just use vim.
https://orgmode.org/manual/Code-Evaluation-Security.html
Following ‘shell’ and ‘elisp’ links Org has two link types that can directly evaluate code (see External Links). Because such code is not visible, these links have a potential risk. Org therefore prompts the user when it encounters such links. The customization variables are:
User Option: org-link-shell-confirm-function Function that prompts the user before executing a shell link.
User Option: org-link-elisp-confirm-function Function that prompts the user before executing an Emacs Lisp link.
Non issue. Rtfm.