Local variables insecurities - Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [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.