Are there any security risks in GNU Emacs?

• the `movemail' incident (No, this is not a risk.) Cliff Stoll in his book `The Cuckoo's Egg' describes this in chapter 4. The site at LBL had installed the `etc/movemail' program setuid root. Since `movemail' had not been designed for this situation, a security hole was created and users could get root priveleges. `movemail' has since been changed so that even if it is installed setuid root this security hole will not be a result. I have heard unverified reports that the 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. If you set the variable inhibit-local-variables to a non-nil value, Emacs will display the special local variable settings of a file that you visit and ask you if you really want them. This variable is not mentioned in the manual. It is wise to do this in lisp/site-init.el before building Emacs:

    (setq inhibit-local-variables t)
  

  If Emacs has already been built, the expression can be put in lisp/default.el instead, or an individual can put it in their own .emacs file. The ability to exploit this feature by sending e-mail to an RMAIL user was fixed sometime after Emacs 18.52. However, any new package that uses find-file or find-file-noselect has to be careful about this. For more information, see `File Variables' in the online manual (which, incidentally, does not describe how to disable the feature). There is a new variable in Emacs 18.58 named ignore-local-eval which turns out to be useless as currently implemented. Ignore it.
• 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 workstatation can make your Emacs process do anything, including run other processes with your priveleges. 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. Lucid GNU Emacs does not accept synthetic X events unless you set a variable.
• autosave file permissions (Yes, a risk, hard to work around.) The file permissions for autosave files are determined solely by the Emacs process's `umask' value. The permissions of the file being autosaved are not used. The easiest workaround is to keep sensitive files in protected directories. Sebastian Kremer has written an enhanced version of the autosave file name picking code that can avoid this problem by keeping autosave files in a protected directory. {FTP information please?} This problem will be fixed in Emacs 19.