Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

security problem in emacs

28 views
Skip to first unread message

Georgi Guninski

unread,
Dec 31, 2002, 7:17:15 AM12/31/02
to bug-gn...@gnu.org, vendo...@lst.de
Hi,

Attached file demonstrates GNU Emacs 21.2.1 starting process if a text file is
opened. Just open it with emacs and check for processes "yes".

I suggest disabling local variables by default, because probably there are
similar bugs of the same nature.

All the best in the new year!

Georgi

emacs1.emacs

Georgi Guninski

unread,
Dec 31, 2002, 9:47:21 AM12/31/02
to Kai Großjohann, bug-gn...@gnu.org
Kai Gro?johann wrote:

> Georgi Guninski writes:
>
>
> >Attached file demonstrates GNU Emacs 21.2.1 starting process if a text
> >file is opened. Just open it with emacs and check for processes "yes".
>
>

> This has been fixed in the development sources. The user is asked
> whether to execute the Lisp code.
>
> Alas, this has not been fixed in the 21.3 pretest.


Is the new attached file also fixed?
It requires mouse over text.

I suggest you disable local variables by default - they are not portable and
some people use emacs for examining untrusted log files or read mail.


georgi

emacs2.emacs

Alfred M. Szmidt

unread,
Dec 31, 2002, 10:14:08 AM12/31/02
to guni...@guninski.com, kai.gro...@uni-duisburg.de
Is the new attached file also fixed?

Emacs CVS gives a warning about the code.

I suggest you disable local variables by default - they are not
portable and some people use emacs for examining untrusted log
files or read mail.

Disabling local variables completely seems silly. Making Emacs warn
the user when running local-hook's or eval's is a far better idea;
which is done in CVS. Local variables are very useful.


Miles Bader

unread,
Dec 31, 2002, 10:30:20 AM12/31/02
to gnu-em...@moderators.isc.org
Georgi Guninski <guni...@guninski.com> writes:
> > This has been fixed in the development sources. The user is asked
> > whether to execute the Lisp code.
>
> Is the new attached file also fixed?

Yes; here's the *Messages* output for that file:

Process `eval' or hook local variables in file x? (y or n)
Ignoring risky spec in the local variables list

-Miles
--
Come now, if we were really planning to harm you, would we be waiting here,
beside the path, in the very darkest part of the forest?


Georgi Guninski

unread,
Dec 31, 2002, 10:42:59 AM12/31/02
to Alfred M. Szmidt, kai.gro...@uni-duisburg.de
Alfred M. Szmidt wrote:

> Is the new attached file also fixed?
>

> Emacs CVS gives a warning about the code.

So since emacs CVS fixes at least 2 security bugs you may think about releasing
a new version or at least patches.

>
> I suggest you disable local variables by default - they are not
> portable and some people use emacs for examining untrusted log
> files or read mail.
>
> Disabling local variables completely seems silly. Making Emacs warn
> the user when running local-hook's or eval's is a far better idea;
> which is done in CVS. Local variables are very useful.
>
>

I continue to disagree that local variables on by default is a good idea, but am
tired of arguing about it.
So here are some last arguments:
1. I found 2 security bugs on release version of emacs in less than week. How
many left do you think are? Of course the idea of warning about eval or hooks
seems good, but covering all cases of non-obvious evals in a large project is
difficult task.

2. Lusers like micro$oft thought in the beginning that scripting in email/word
is a good idea and it is sandboxed. Now it is off by default in their email
products. Think about it.

3. Local variables are not portable accross editors, which makes them almost
useless, unless every document has all the version of local variables for every
editor.

georgi


Miles Bader

unread,
Dec 31, 2002, 1:00:29 PM12/31/02
to gnu-em...@moderators.isc.org
Georgi Guninski <guni...@guninski.com> writes:
> 1. I found 2 security bugs on release version of emacs in less than
> week. How many left do you think are? Of course the idea of warning
> about eval or hooks seems good, but covering all cases of non-obvious
> evals in a large project is difficult task.

To be fair, both your examples were already taken care of.

> 2. Lusers like micro$oft thought in the beginning that scripting in
> email/word is a good idea and it is sandboxed. Now it is off by
> default in their email products. Think about it.

This is not scripting. Whether or not emacs is as restrictive as it
should be, I don't know, but there's clearly a large subset of
variables/values that can quite safely be set.

Yes, if emacs were the kernel, it would have to take a more conservative
approach -- but it's not, and convience _is_ important.

[Of course, it helps that the `local variables' section is not
interpreted for such obviously suspicious sources such as email or news,
and that emacs users are in general a more clueful lot than typical MS
product users]

> 3. Local variables are not portable accross editors, which makes them
> almost useless, unless every document has all the version of local
> variables for every editor.

Who cares about other editors? I certainly don't.

-Miles
--
`Cars give people wonderful freedom and increase their opportunities.
But they also destroy the environment, to an extent so drastic that
they kill all social life' (from _A Pattern Language_)


0 new messages