From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qGLTAtlQvl8rVAAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 12:40:57 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qE62OdhQvl8JWAAAbx9fmQ (envelope-from ) for ; Wed, 25 Nov 2020 12:40:56 +0000 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 201C69403CA for ; Wed, 25 Nov 2020 12:40:56 +0000 (UTC) Received: from localhost ([::1]:43070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khu6R-0002Bu-3A for larch@yhetil.org; Wed, 25 Nov 2020 07:40:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khu4B-0002B7-7t for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 07:38:35 -0500 Received: from static.rcdrun.com ([95.85.24.50]:53153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khu48-0008DH-JK for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 07:38:35 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000B.000000005FBE5047.000072E8; Wed, 25 Nov 2020 12:38:30 +0000 Date: Wed, 25 Nov 2020 15:38:09 +0300 From: Jean Louis To: Tim Cross Subject: Local variables insecurities - Re: One vs many directories Message-ID: References: <87mtz84om9.fsf@localhost> <87ft4zhyuo.fsf@disroot.org> <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> <87y2iq6itk.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y2iq6itk.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: 1EiwSKJrb94C * Tim Cross [2020-11-25 09:41]: > >> Why is it a security issue? The variables do need to be close to the end > >> — 3000 characters is only about 50 lines. > > > > Emacs users, Org users on our mailing lists are not so private. Their > > names and email addresses are in the public database. Spammer can > > construct phishing type of an email, including something like Org news > > or something and send such email to users. Among let us say 3000 > > people there will be percentage of users that will say Y to invoke the > > local variables due to lack of knowing what is it doing to computer. > > > > After that, anything becomes possible, including intrusion into > > computer, capturing all email addresses, passwords, sending spam > > emails from computer and so on. > > this is just baseless fear mongering based on nothing but > speculation. My experience with such people come from last more than 25 years. CVE list is the reference I already quotes. Some thing were improved like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684695 So one should know how dangerous it was to introduce local variables with possibility to automatically eval anything there. > Of your suggested 3000 users, only a very small percentage use Emacs as > their mail client. Those which I know through Emacs list mostly use it. I am using it. Is there any way to know who use and who not? In general I am reading emails with Mutt, but I am answering with Emacs. Sending emails is often by Emacs or by Mutt. I use sometimes M-x rmail as well > Of those, only an even smaller number will have their mail client > configured to render messages with a mode that supports local I have not configured anything. In fact I have opened the email and I was surprised that I am getting those dialogues to execute local variables. And I an in mail-mode now. Mutt opens new emacsclient and I edit the file. Obviously user does not need to configure anything. You maybe refer to specific mode where it does not execute. It will try to execute even if I open .TXT file. The very design of Local variables I do not find trustful for these explained reasons. I do not protest against it as now is too late, but as I mentioned more educational references could be provided in the dialogue that asks user to execute local variables or not. > variables and even a smaller number of those would say yes to > executing the code. In fact, anyone who has gone to the extent of > configuring their Emacs email client to open messages with a mime > type of x-org (or even just based on an attachment with *.org in the > file name) is more than likely to be sufficiently technically aware > not to say yes when asked. I do not need to configure emacs to anything to get the local variable execution dialogue, verify it on your side. I can basically get any attachments by email, try to view them in Emacs and it will execute. > Few, if any user, is going to download some random attachment in an > email message Sorry, but I have no choice but to download all attachments. Majority of email clients do not offer choice to download specific attachments they download whole message as one. > open it in emacs and then say yes to a message warning them that > doing so might be dangerous. It does not warn to be dangerous. There is no word of danger in the dialogue. I would rather like the dialogue to does what you say but it does not, I would prefer it like this: =========== DANGEROUS =========== But it is not like that, and I have elaborated why it is not like that. Text writers are not programmers. You assume that every user starts from your viewpoint of 30 years experienced Emacs wizard. And I am speaking of design view point. Emacs is still called "editor" today. The description of Emacs I get in Hyperbola GNU/Linux-libre is: The extensible, customizable, self-documenting real-time display editor, without D-Bus support Nowhere it says in the description that it can potentially expose me to malicious evaluations of software just by opening a text file. That you know what Emacs is really and me too, it does not make it more secure. We make assumptions that we will know that users will be safe, but that is wrong assumption and there would be no CVE as I have already referenced it it it would be so. > Such ill-informed users have been pretty much weeded out by all the > other scam phishing out there by now. I would not say so. As non-native English speaker to say for users that they are ill-informed sounds to me not appropriate. We invite users to use Emacs, they will download, open, and may be offered to read the ebook or other interesting text, and text will ask them to evaluate the variables. You say that the subset of those users who will know what is "variable", "value", "evaluation", "safe" is small and not important, and I think this is most important for the future of next 100 years for Emacs being useful to many people. For that reason I cannot call such users ill-informed, rather not informed and coerced into decisions which they are not able to take as they are not informed. > To convince them to go through such steps would require some pretty > convincing content - a simple org news attachment or similar is > unlikely to do it. Maybe you get informed, that is very easy, easier than you think. There are many ways to do that and that is very simple by tricking users, as Emacs related mailing lists are harvested and from time to time users can be sent emails and emails can offer them themes, programs, to trick them. It is very easy to convince users. Examples from other computing areas on how users are tricked: https://news.softpedia.com/news/Facebook-Users-Tricked-into-Loading-Malicious-Code-in-Their-Browsers-146604.shtml https://techcrunch.com/2019/08/16/android-users-tricked-adware-apps/ https://www.independent.co.uk/life-style/gadgets-and-tech/news/google-chrome-adblocker-fake-download-scam-users-tricked-adblock-plus-extension-a7992711.html https://www.dailymail.co.uk/sciencetech/article-4682528/Facebook-users-tricked-sharing-hoax-message.html https://www.offthegridnews.com/privacy/facebook-users-give-personal-data/ > Even if you do get them to say yes, they are still a long way from > being able to compromise the computer Emacs is running on. I cannot be sure to what you refer. If email is sent to 10,000 people there will be subset of people who will say yes, and what is programmed in the local variables could be anything. > Gaining some level of access is one thing, actually being able to do > something with that access is another. Trying to compromise a > computer, which these days typically involves privilege escalation, > would be extremely difficult to achieve with elisp. Fetch from Internet and execute. That is what majority of intruders do. If you are not intruder you cannot know. There are rootkits everywhere on Internet. Fetch and execute. Sometimes simpler than that. > The best you could hope for would be to install a trojan or back > door what would allow the attacker to install other tools. Could be > possible, but is definitely non-trivial. Exactly. Experience over 18 years with server administration tells me about that. > This ability has been around in Emacs for a very long time - more than > 30 years, possibly even longer. There has not been a single recorded > incident of large number of users being compromised as a result of this > feature. Also the intrustions that have taken place on hosting servers I have not reported anywhere. It is not relevant really and I have explained that when intrusion does happen user may not go to report to the list or connect to experienced hackers. On the other hand user is faced with a dialogue that requires user to know what is programming, variable, value and safe. Users do not know. Today I was watching Ralph that broke the Internet and somebody mentioned to him "safe" and he said he feels safe. That reminds me of that dialogue. Something contains values that may not be safe? Well I am safe, damn YES. When expressing "safe" one has to say about the context, safe from what? > I've not even heard of small numbers being compromised as a result > of this feature. You can as well make program popular and root and need not hear of it ever. There is plethora of programs that one does not hear of it, why should you hear of it? When there is really good way to intrude into people's computers those are not published for everybody to know. Facebook data was downloaded continually by intruders back in time. I remember before 16 years a simple website that I reference to a friend in the same room could give me access to all his files. It was amuzing. Today there are many problems with Javascript and Emacs is just maybe not so wide spread to invoke public incidents. The CVE list should be enough to say that there are security incidents coming again and again. > I'm sure you will disagree. My suggestion is that if you believe > this is a security issue, you put together a proof of concept to > demonstrate the vulnerability - this is how such security issues get > resolved. Just put eval: do anything malicious. That is simplest. Fetch URL, save, chmod, execute. Anything can be there. > Demonstrate how the security issue can be exploited with actual > proof of concept code rather than mere speculation and that will > provide something concrete which can be dealt with. I suspect you > will find it much harder to achieve once you actually try to make it > work. Well, you say so, but this one worked pretty well: # Local Variables: # eval: (progn (delete-file "/tmp/new/new") (message "Done")) # End: I could as well send files to myself by using their email system whatever is there like mail, mailx, mutt, maybe Emacs stuff as well. Or I could send me their password store, I could get ~/.authinfo, or maybe even test if sudo works without password and then place my insecure DNS servers and redirect to phishing websites. Just anything becomes possible with Emacs variables.