Re: Undocumented RCE potential with emacsclient and socket forwarding

Perry Fraser [24/Jul  3:58pm -04] wrote:
> emacsclient has an `--eval' option which can be used to execute arbitrary lisp on the relevant emacs server. This ends up being a problematic combination with socket forwarding, something which is documented in `(emacs) emacsclient Options' under the section for `--tramp'. This /doesn't/ mention that this should only be used with completely trusted remotes as it means anyone with access to the forwarded socket can execute arbitrary code on the emacs server's host. This is unexpected to me as a user as I expected there to be few additional capabilities to the emacsclient protocol besides "open a file on my emacs server process".
>
> It seems to me there are two possible improvements that could be made here:
>
> 1. Explicitly document the security implications of forwarding your emacs server socket to a remote host, and how it enables remote code execution for anything that has access to the socket's FD.
>    - This all similarly applies for when `emacs-use-tcp' is set, where you would need both local network access as well as file access to wherever your server file is, per `(emacs) TCP Emacs server'.
> 2. Add a customizable variable that lets the emacsclient's protocol's `-eval' command be a no-op.
>    - While the backwards-compatible way would be making this default to allowing `-eval', I would personally argue that it should be an opt-in to use that behavior.
>    - As far as I can tell, the `--eval' flag is the only way that the `-eval' command is sent by emacsclient, so there's no unexpected loss of functionality here. (Obviously `--eval' does have real use-cases such as `emacsclient -e "(kill-emacs)"'.)
>
> A third option would probably be something involving `unsafep' but I know next to nothing about it or its suitability here.

I think it would be okay just to document it.

FWIW as a user I would not expect that a forwarded socket would be
locked down in any particular way.

-- 
Sean Whitton