From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WylLF2E3s2O5HgAAbAwnHQ (envelope-from ) for ; Mon, 02 Jan 2023 20:58:25 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id +POTFmE3s2O+RQAAauVa8A (envelope-from ) for ; Mon, 02 Jan 2023 20:58:25 +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 B418933527 for ; Mon, 2 Jan 2023 20:58:24 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCQw1-0007dN-S7; Mon, 02 Jan 2023 14:57:25 -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 1pCQw0-0007ao-GF for emacs-orgmode@gnu.org; Mon, 02 Jan 2023 14:57:24 -0500 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pCQvy-0007xi-5D for emacs-orgmode@gnu.org; Mon, 02 Jan 2023 14:57:23 -0500 Received: by mail-pf1-x42b.google.com with SMTP id e21so9650757pfl.1 for ; Mon, 02 Jan 2023 11:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:from:to:cc:subject:date:message-id:reply-to; bh=Bc0Dg+bkbrAUcQ8o3z8jD17R0YZvl43c2FYgq19xkow=; b=V4t/edvhGL9h+5nRdAso4/jlNGye7EqmW4fST+/8+PaxvXRO03CBVEPL+1Qf5aU4kJ YjGfJpUetCu5agw9cGiLeq1USZuPWxNIPr2itIf6jEjH1NNPu6NOoMyJLofHGkvVB3oT RVgn/K4BeLsnwZw+KrSb8mtaTZcJLbLqrtKmqiGy8AUvKJMwBCRRlq2JF+VfM+Edvy7j f5MTtdC2czkGJoVKbAMPsgPluvpsChnUpXcoLoFZgxQCRwZq0DLDz2O8tEfgNWICYs89 AmvOrE7rb9jYvR8HGHjDifD7v/nUtO/0+lL5mUUWeN8S7su46gzF6INcPvYkpdjkSvBu JHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bc0Dg+bkbrAUcQ8o3z8jD17R0YZvl43c2FYgq19xkow=; b=uUz21i5nodVh0n6S3lqC6wb6fUS+vJdHKkyv8abYegnLj8Alocekm1bkTuJhIVLQda CTCA9/WzBkVeV1jySrArJsxWzGTQ6AlBWMyE9OiR9GbhRv8H6hAB0m9XMj9oJdhszC5O AuuFJZIfDewSzbmompdG+pSYqcx+l4dQso1Whb+HEI3SPsM1oyU4k1/O4cgiDcJADDwY xrSW7IFio8FDBP6uqtOCwwJs3NCRRvTAynpz6Azca2BEPWotif0LtmbF1Kj4fWv9+k0m tY1vjvMbQQ9Lu9amJzfQ7U8vPmhNUrLiHVE5ZEMeycuthvfkf/49C6gK6KRj9ySuLcZi b9og== X-Gm-Message-State: AFqh2kqzInjJucZKHijYaAkxer5IvXK6fu+CaDcghP3/7d8y7fQGAIQV uKfo1i+OwO6085U77th9iu7bCQnUYAc= X-Google-Smtp-Source: AMrXdXt2BEd8sLRUWZxAZGB9HFsMgT/crEjI9nlQylnrfkYW1LCb5x501s/o09LUw8OAOuL793qeUQ== X-Received: by 2002:a05:6a00:3217:b0:580:ffa0:bfcf with SMTP id bm23-20020a056a00321700b00580ffa0bfcfmr29048267pfb.6.1672689439828; Mon, 02 Jan 2023 11:57:19 -0800 (PST) Received: from dingbat (203-173-24-107.dyn.iinet.net.au. [203.173.24.107]) by smtp.gmail.com with ESMTPSA id l190-20020a6225c7000000b005771d583893sm19371928pfl.96.2023.01.02.11.57.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jan 2023 11:57:19 -0800 (PST) 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> <87edsd5o89.fsf@localhost> User-agent: mu4e 1.9.10; emacs 29.0.60 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) Date: Tue, 03 Jan 2023 06:00:45 +1100 In-reply-to: <87edsd5o89.fsf@localhost> Message-ID: <86tu18d811.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42b; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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-Seal: i=1; s=key1; d=yhetil.org; t=1672689504; a=rsa-sha256; cv=none; b=H7BUwibAfQaH+nJqBZwHSs5bO0ZO55r1sZ/xZ4mtlHoh366ptR4E0QV397WaBnAA220CMN mBYGG5gctFUMt2iF+1LtMcj1A0fk73YYk7K+9dVjJd9OwcERUukQXlQiPq2zpImTJDHrkw drh3dxgAmjO/QCmCgfICkLGD6yOr4CeCO2xTmsRn9g63TTkwarDegGAMmqF8TCPTKHg/pZ y++nBoUqCMwHYtlMYgRRccbdkE00OF4wmwTVMsR44XzBgyD6XLQBS98LOqe/pD3KuBxkeJ 3BRnjuYMW6TWTT2oqq7YVHVqGfzDjg8AkG3y51tHKUwfJeJNASXqAvlVX/FrgQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="V4t/edvh"; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672689504; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=Bc0Dg+bkbrAUcQ8o3z8jD17R0YZvl43c2FYgq19xkow=; b=PGXy398age//BHByrMwimdRPfM2qEUeOA62GXf1hTuZ+pMpVjsGq/sjrVfb6/0Jq72w7TU Kxfgq7VO0g52UViaEHGF1hsdjFfFfOYH32wKqHczRBe+SbvqkweJG/aehluNMjGxVqUHQi k6fYuMdmqskalAn1QnNF5IZpUFiftGX7AystJg2wrGRYZvoBSEioJ5FXvJ14PBq4qwK6pl RuOydYODYf40WZYN3CBblIiWH5ms/sW7sR4xSOkEM08v9ZS4NPNRhn1qvpe93dIOZxxTBb majXd4K9+LHvcwFGUa6KKmFfplyBjBAhMDMJXx1+PI75ohtAc7XwxQGGVd4kOg== X-Spam-Score: -11.76 X-Migadu-Queue-Id: B418933527 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="V4t/edvh"; 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=gmail.com X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -11.76 X-TUID: pafVMDR1bzwo Ihor Radchenko writes: > 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? Hi Ihor, this looks promising. However, there is a lot to be considered here and it requires some thought before any meaningful feedback can be provided. The big challenge here will be in getting sufficient fine grained control that all use cases can be catered for while also providing a high level interface suitable for the 'general' case which is both reasonably easy to understand at the user level and flexible enough for a default configuration. For many users who don't share org files, who work on a single user desktop and who implicitly trust the files they are working with, it is unlikely they want to be bothered by any of this. It should 'just work'. I suspect this is the majority. Others will have some sharing of documents - perhaps in a work group, a class or some form of team activity. The trust here is likely fairly high but perhaps not absolute. There is probably a need for some choice on execution on a per file basis. Finally, there are those org files which are from unknown and therefore untrusted sources - email messages, cloned git repositories, Emacs packages, etc. Most people likely don't want these executed by default and want to be asked or be able to block by default. The point is, we probably need to consider not only what variables are required, but also some infrastructure for managing those variables based on some form of document classification or trust. You touch on this with some of what has been outlined, but it focuses on the original data source. That information can be lost once a file has been retrieved. However, the trust level of that file likely doesn't change just because it now resides 'locally'. I do wonder if the idea of a document classification model and some form of heuristic algorithms to handle default document classification might be useful. The idea is similar to other security systems which classify documents/files and tags those files with their classification whereby other services (email, http, sftp, etc) implement policies which impose restrictions on files based on the tag. While this is a different use case, I do wonder if such idea might help here e.g. the default setting for various variables controlling code execution are set based on the tag of the file, which in turn is set based on the heuristic for that file. For example, *.org files created in Emacs by the user/owner might have the highest 'trust' tag while those which originate in Email or from external links might have the lowest unless the link/source is flagged as trustworthy. We could have a mechanism whereby you define a trust 'tag' which in turn defines the various variables associated with control of code execution. We would then define a mechanism for defining a 'rule' to classify org files, allowing users to define their own heuristics and define a base set of tags and rules which define default behaviour. The tags could be a header variable or an emacs file local variable etc. There could be rules triggered for files opened without a tag or a mechanism defined for a default tag (or perhaps a function which could, as one option, ask the user when the file is first opened and no tag exists etc). Of course, the devil is in the details. For example, how do we handle the case where you and I are sharing a file and we want different tags? (we would likely need some form of simple 'signing' for tags and ability to have multiple tags per file or forced 'review' of tags not originating form the user etc). Somewhat related, if Timothy is reading this thread, I wonder if some questions in the next Emacs survey might be useful (or if an org specific survey would be useful) in order to get some real data on user use patterns and data sources etc. It is possible that the use case for org files with untrusted code is so small that none of this is actually necessary and we could just handle it by making the risks very explicit and leave the user to decide on how they want to mitigate the risks. There is one school of thought which would state that if you are unable to define a reliable and understandable security model which works, your better off just educating the user base and leaving it to them to manage in whatever manner is best suitable for their situation. A model which is hard to understand or which doens't work runs the risk of creating a false sense of security and may do more harm than no model and a big red sticker which says "Beware of the tiger!".