From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id +MeOHzmXsmM1QQAAbAwnHQ (envelope-from ) for ; Mon, 02 Jan 2023 09:35:05 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id OKOIHzmXsmObXgEA9RJhRA (envelope-from ) for ; Mon, 02 Jan 2023 09:35:05 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 188C9193CF for ; Mon, 2 Jan 2023 09:35:05 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCGGo-0001nL-Mb; Mon, 02 Jan 2023 03:34:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pCGGn-0001nD-9X for emacs-orgmode@gnu.org; Mon, 02 Jan 2023 03:34:09 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pCGGl-0005HV-3g for emacs-orgmode@gnu.org; Mon, 02 Jan 2023 03:34:09 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 50B0624023F for ; Mon, 2 Jan 2023 09:34:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1672648445; bh=K8fCsmVws2b5ZxYJFPxrRbXOu5GoTBzypS1IobdW5KQ=; h=From:To:Cc:Subject:Date:From; b=qFkGmMm3CbMC0kQ7aT1t3uJiQ/jbTZYzPFPwHxMm4ZxuIBeHxxG+m2nTfVSlISK2m G8bQ3X17LO0e46Dme3kANe7vwiIZBEWd7OnQSN+NyQDrIvGTEJOhwHoFD51Al7ddSb cp3JBZ6Qv3l84YKbewpJ68mLPuG3rYdyaG3uBnUMjkVsMi+vBGKcOg+Di6yKVm4+ky 0uXhrwWqUqLKn8U5wuzl2bDSjmTTECXQIfqLhQc8Q1eKS5d98Duw6l010nDqGpoxrM bFlWjNcaAW7qROrCPYDzmRDh0z3uZ59bXWWCfNiTDT2sCmRUzT+jtfm5anjfSOnQCy EeIxI1A+VOieQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Nlq075mHSz6tn9; Mon, 2 Jan 2023 09:33:59 +0100 (CET) From: Ihor Radchenko To: Tom Gillespie Cc: Bastien , Kyle Meyer , emacs-orgmode@gnu.org Subject: [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) In-Reply-To: <878rinadlq.fsf@localhost> References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87k02fspxa.fsf@localhost> <87edsii4mo.fsf@gnu.org> <87h6xetbfn.fsf@localhost> <878rips273.fsf@bzg.fr> <878rinadlq.fsf@localhost> Date: Mon, 02 Jan 2023 08:34:30 +0000 Message-ID: <87edsd5o89.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672648505; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=O3jK/y+C6+88LMRHLVcFGah6PmbN5xZ9JrnOlvrtX38=; b=VLqhBmFpsQRjZnjpsC9uxWaMdfQ7Y3dxxBE8Jzi/SR+Xd6W5KpqwZVKpagp+j1wQDzt7za GHdS5MIgvMDrmr88zLfAKzBuc7Ar/+73tg0E8ot266Yg2B6RTfofVc8si2RYd6z0m3mmVI duhtLnlMpCYJNs3qV8/OQn7VcFfSjGIgnevj+9+EZ6GK9SU1T25kUU81N0QVKwKAYokF4f DIWxjofiCIyPPUKhZFMUfCyZIUzYlq6hXNlAHEXQ/Jg+vaPLJ4RvMsAdVGcbYCDCcOYI9r NpHMGCJKqgaablDkGo3R8uTNt7AHPVPnLFl3mz1A9vhZNq0yRCF1Xf4RHMuAEg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qFkGmMm3; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672648505; a=rsa-sha256; cv=none; b=Mk8AWdv9sC0HKgUWxYBy64e/q2BqMuiTmX4qvEy4ewHRNjpATu0Z+Y1SAchTALNE36/L+t JV/xdyPdLyDhj7ixgGjeT7bUybgx+U6TRuE7BmY5t0I8Re2j/1BapxmrHui+1d3f9qhtZg 6PKa1PUk7PxBhQoXfzRud9JKJoJGtcWr8yHRVk1ggDkkDoG+aMKlF5QOR9vUygKLypFpwt 79iE8UJozM+XbJlk5np/g/Jb2ZQ1RJhFucjFInSjGJUUcFSZM9d6XXwMMIhtLZRcWkuhgG n06pWUid1a4vjJ5wKs74Hxmi2MVRnVH6PGG8ZETzfwmaxwtRj9F0lT21JBu6YA== X-Spam-Score: -5.99 X-Migadu-Queue-Id: 188C9193CF Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qFkGmMm3; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -5.99 X-TUID: nXNie5+j8uWk Ihor Radchenko writes: > P.S. Considering intense discussion around the topic, what about > reverting my commit from the release? We can then re-consider the whole > design and apply something more elaborate later. I now reverted the discussed commit. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=345402148 We need to come up with a uniform security system where all the code evaluation is (1) easy to control via variables and user queries; (2) not too annoying for users; (3) provides the necessary context for users to decide if a code is safe to run. Before we continue the discussion, I will try to summarize the current state of Org manual and code wrt code evaluation of the code coming from Org documents (including downloaded Org files). In the manual we now have 17.13 Code Evaluation and Security Issues This section talks about 1. Source block bodies and `org-confirm-babel-evaluate' 2. shell/elisp links and `org-link-shell-confirm-function' + `org-link-elisp-confirm-function'. Notably, `org-link-elisp-skip-confirm-regexp' is not mentioned in the manual. 3. Table cells, with no way to query or disable execution. In reality, we have many more places in the code where arbitrary text from Org files can be evaluated. I have marked some places in the above commit with FIXME. >From my audit of Org sources the following scenarios may lead to arbitrary code execution: 1. Code block bodies 2. Elisp sexps in header args. Notably, not only `org-babel-read' is responsible for evaluating header args. :results and :exports are evaluated independently. 3. Table cells 4. "eval" macros during expansion 5. Diary sexps To the best of my knowledge, this list should be complete. Though I would appreciate someone double-checking. -------------------- According to the above: - `org-confirm-babel-evaluate' allows either using `org-babel-confirm-evaluate' prompt (when t), not asking at all (when nil), or using arbitrary prompt function. - `org-link-shell-confirm-function' + `org-link-elisp-confirm-function' are similar, except defaulting to `yes-or-no-p'. - `org-link-elisp-skip-confirm-regexp' extends indiscriminate function queries to also skip certain (single) regexp. The situation is not ideal. We have similar, but more detailed system for downloading remote files: - `org-safe-remote-resources' allows users to define certain files/urls that are known to be safe - `org-resource-download-policy' provides choice between "always query", "query unless safe", "never download", and "always download" Also, `org--confirm-resource-safe', unlike `org-babel-confirm-evaluate' allows manipulating `org-safe-remote-resources' interactively by marking current URL or URL domain safe for future. ------------------------ What we can do 1. Introduce a new customization `org-confirm-evaluate-safe-regexps' listing regexps that are considered safe or cons cells (src-body/header-arg/table/macro/diary . regexp) 2. Introduce a new customization `org-confirm-evaluate' that can be set to t/nil/prompt/safe/[function]/[alist]: - t/safe :: to display default prompt unless the code block in buffer is marked safe - prompt :: always ask (the prompt will then not display options to add current sexp to safe list) - [function] :: custom function that returns t/safe/prompt/[alist] - [alist] :: (src-body/header-arg/table/macro/diary/t . t/safe/prompt/function) (t . ) stands for default value. 3. The default prompt will mimic `org--confirm-resource-safe', additionally accepting Y/N to accept/decline all the evaluation in current command. This system will be used across Org for code evaluation. Old variables will be supported, but obsoleted. WDYT? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at