efaq: Security risks with Emacs
6.10 Are there any security risks in Emacs?
===========================================
• The ‘movemail’ incident. (No, this is not a risk.)
In his book ‘The Cuckoo’s Egg’, Cliff Stoll describes this in
chapter 4. The site at LBL had installed the ‘/etc/movemail’
program setuid root. (As of version 19, ‘movemail’ is in your
architecture-specific directory; type ‘C-h v exec-directory <RET>’
to see what it is.) Since ‘movemail’ had not been designed for
this situation, a security hole was created and users could get
root privileges.
‘movemail’ has since been changed so that this security hole will
not exist, even if it is installed setuid root. However,
‘movemail’ no longer needs to be installed setuid root, which
should eliminate this particular risk.
We have heard unverified reports that the 1988 Internet worm took
advantage of this configuration problem.
• The ‘file-local-variable’ feature. (Yes, a risk, but easy to
change.)
There is an Emacs feature that allows the setting of local values
for variables when editing a file by including specially formatted
text near the end of the file. This feature also includes the
ability to have arbitrary Emacs Lisp code evaluated when the file
is visited. Obviously, there is a potential for Trojan horses to
exploit this feature.
As of Emacs 22, Emacs has a list of local variables that are known
to be safe to set. If a file tries to set any variable outside
this list, it asks the user to confirm whether the variables should
be set. You can also tell Emacs whether to allow the evaluation of
Emacs Lisp code found at the bottom of files by setting the
variable ‘enable-local-eval’.
(emacs)File Variables.
• Synthetic X events. (Yes, a risk; use ‘MIT-MAGIC-COOKIE-1’ or
better.)
Emacs accepts synthetic X events generated by the ‘SendEvent’
request as though they were regular events. As a result, if you
are using the trivial host-based authentication, other users who
can open X connections to your X workstation can make your Emacs
process do anything, including run other processes with your
privileges.
The only fix for this is to prevent other users from being able to
open X connections. The standard way to prevent this is to use a
real authentication mechanism, such as ‘MIT-MAGIC-COOKIE-1’. If
using the ‘xauth’ program has any effect, then you are probably
using ‘MIT-MAGIC-COOKIE-1’. Your site may be using a superior
authentication method; ask your system administrator.
If real authentication is not a possibility, you may be satisfied
by just allowing hosts access for brief intervals while you start
your X programs, then removing the access. This reduces the risk
somewhat by narrowing the time window when hostile users would have
access, but _does not eliminate the risk_.
On most computers running Unix and X, you enable and disable access
using the ‘xhost’ command. To allow all hosts access to your X
server, use
xhost +
at the shell prompt, which (on an HP machine, at least) produces
the following message:
access control disabled, clients can connect from any host
To deny all hosts access to your X server (except those explicitly
allowed by name), use
xhost -
On the test HP computer, this command generated the following
message:
access control enabled, only authorized clients can connect
Info Catalog
efaq: Shell mode loses the current directory
efaq: Bugs and problems
efaq: Dired claims that no file is on this line