[HN Gopher] Arbitrary shell command evaluation in Org Mode (GNU ...
___________________________________________________________________
Arbitrary shell command evaluation in Org Mode (GNU Emacs)
Author : todsacerdoti
Score : 63 points
Date : 2024-06-23 15:38 UTC (7 hours ago)
(HTM) web link (seclists.org)
(TXT) w3m dump (seclists.org)
| ww520 wrote:
| 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.
| tsujamin wrote:
| 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.
| smitty1e wrote:
| 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.
| exe34 wrote:
| might be good if it's not "auto run", but otherwise running
| code inside org-mode is definitely part of the appeal.
| livrem wrote:
| Yes, but that is not what the linked vulnerability is about.
|
| https://orgmode.org/worg/org-contrib/babel/intro.html
| metroholografix wrote:
| Unexpected evaluation is never a feature, Emacs should at least
| warn and prompt before executing code in a file that somebody
| opens.
| ykonstant wrote:
| I am on the camp that agrees with that, but there are many
| who don't :/
| nequo wrote:
| 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.
| bachmeier wrote:
| 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
| metroholografix wrote:
| 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
| hsbauauvhabzb wrote:
| 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.
| metroholografix wrote:
| 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.
| bloopernova wrote:
| The vulnerability is that Emacs evaluates this automatically:
|
| #+LINK: shell %(shell-command-to-string) [[shell:touch
| ~/hacked.txt]]
___________________________________________________________________
(page generated 2024-06-23 23:00 UTC)