[HN Gopher] Arbitrary shell command evaluation in Org Mode (GNU ...
___________________________________________________________________
Arbitrary shell command evaluation in Org Mode (GNU Emacs)
Author : todsacerdoti
Score : 112 points
Date : 2024-06-23 15:38 UTC (1 days 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.
| hobs wrote:
| Code snippets as text is denuded but word documents are
| good for code... what universe is this?
| smitty1e wrote:
| Word vs. Outlook
| 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
| jlg23 wrote:
| 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.
| cobbal wrote:
| 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: ;; -*- eval: (message
| "arbitrary code") -*-
|
| any mode associated with a file extension should be at
| least as secure against code execution.
| bachmeier wrote:
| 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.
| pama wrote:
| 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.
| 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.
| a1369209993 wrote:
| > 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.
| metroholografix wrote:
| 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/e
| ww/Over...
| bloopernova wrote:
| The vulnerability is that Emacs evaluates this automatically:
|
| #+LINK: shell %(shell-command-to-string) [[shell:touch
| ~/hacked.txt]]
| wiredfool wrote:
| Is that only if the file has a specific extension? I'm not
| seeing it with a .txt extension.
| accoil wrote:
| 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.
| SEJeff wrote:
| Clearly, if you care about security here, the best thing is to
| just use vim.
| ungamedplayer wrote:
| 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.
___________________________________________________________________
(page generated 2024-06-24 23:02 UTC)