GNU Info

(efaq)Security risks with Emacs

---

Next: Dired claims that no file is on this line Prev: Shell mode loses the current directory Up: Bugs and problems

---

Enter node , (file) or (file)node

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.

     Emacs 18 allowed this feature by default; users could disable it by
     setting the variable `inhibit-local-variables' to a non-nil value.

     As of Emacs 19, Emacs has a list of local variables that create a
     security risk.  If a file tries to set one of them, 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'.

     For more information, Note: 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