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.
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