Potential security issue

[mkcms]

The function eglot--format-markup calls a function chosen by the server, to enable a major mode which will fontify a string. However, it doesn't check if this function is safe to call, or if the function would enable some major mode at all.
This makes it a potential security issue.

For example, evaluating the following code will make Emacs unkillable (except by a signal):

(eglot--format-markup '(:value "" :language "emacs-lock"))

These will trigger a nonlocal exit:

(eglot--format-markup '(:value "1" :language "read-only"))
(eglot--format-markup '(:value "1" :language "edebug"))

[joaotavora]

This makes it a potential security issue.

...in the (reasonably rare) case that you're connecting to server to severs running non-locally, otherwise it's an attack vector totally contained inside another attack surface.

[mkcms]

...in the (reasonably rare) case that you're connecting to server to severs running non-locally, otherwise it's an attack vector totally contained inside another attack surface.

We do make it possible nevertheless, without even any warning.
I don't think anybody would ever expect a server to do anything other than providing information to the editor.

Also, it is a security issue in other situations. Consider the scenario where you install pyls from PyPI and run it as another user from within emacs. After one update to pyls (maybe done automatically), an attacker can literally do something on another user account.

I strongly support removing this dangerous behavior.

[joaotavora]

Also, it is a security issue in other situations. Consider the scenario where you install pyls from PyPI and run it as another user from within emacs.

You mean installing pyls as the root user surely. That's the only other plausible scenario. If so, and if pyls is compromised, then you've already lost long before it tries to trick emacs into running some maleovolent elisp function.

I strongly support removing this dangerous behavior.

I agree. I was just helping you measure the extent of the "danger"

[mkcms]

You mean installing pyls as the root user surely

Why? You can run these programs as an unprivileged user, run them with different cgroups, or even in a container which shares some part of a filesystem.

[joaotavora]

You mean installing pyls as the root user surely

Why?

I meant to ask this: in what situations do you see yourself installing pyls a user X and running it as user Y? The only plausible situation where I can imagine this is if X is root and Y is a normal, unpriveliged, user. Do you see any more? If so what are X and Y?

[mkcms]

I meant to ask this: in what situations do you see yourself installing pyls a user X and running it as user Y?

I can imagine myself doing this:

1. Install pyls as non-root user X in $HOME
2. Start emacs as user X
3. Evaluate (add-hook 'python-mode-hook #'eglot-ensure)
4. Find the file /etc/unimportant.py (still, as user X)
5. Find the file /sudo::/etc/important.py because completion failed me when I wanted /sudo::/etc/important.pie (which can happen because when you hit TAB during typing, emacs displays a password prompt, and you can instinctively press RET to hide Tramp's "connected" message)
6. Because I am visiting a buffer with /sudo:: I can now do (shell-command-to-string "cat /etc/shadow")

[joaotavora]

Indeed that seems to me like a big security hole in tramp/emacs. Just because I requested sudo elevation to read and write a specific file, doesn't mean I want sudo elevation for arbitrary commands. Indeed, given this attack vector, why would anyone target pyls/eglot and not just some elisp library???

…

On Mon, Nov 19, 2018, 19:32 mkcms ***@***.*** wrote: I meant to ask this: in what situations do you see yourself installing pyls a user X and running it as user Y? I can imagine myself doing this: 1. Install pyls as non-root user X in $HOME 2. Start emacs as user X 3. Evaluate (add-hook 'python-mode-hook #'eglot-ensure) 4. Find the file /etc/unimportant.py (still, as user X) 5. Find the file /sudo::/etc/important.py because completion failed me when I wanted /sudo::/etc/important.pie (which can happen because when you hit TAB during typing, emacs displays a password prompt, and you can instinctively press RET to hide Tramp's "connected" message) 6. Because I am visiting a buffer with /sudo:: I can now do (shell-command-to-string "cat /etc/shadow") — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#154 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXnwwC6lbTp3-J2X8H8s2SIPmx9qtXnks5uwwc6gaJpZM4Yng_l> .

[mkcms]

Indeed, given this attack vector, why would anyone target pyls/eglot and not just some elisp library???

Maybe because even if there is an Emacs library insert-gpg-key-in-random-buffer-mode which is used by advanced users, an attacker still needs a way to call it from outside Emacs :-)

[joaotavora]

Maybe because even if there is an Emacs library insert-gpg-key-in-random-buffer-mode which is used by advanced users, an attacker still needs a way to call it from outside Emacs :-)

He'll probably find it's much easier to use emacsclient for that

[mkcms]

He'll probably find it's much easier to use emacsclient for that

Interesting, although AFAICS it's not possible for a non-root user to access other's sockets, I tried running a server and then emacsclient as another user.

emacsclient: Invalid socket owner
emacsclient . -s /tmp/emacs1000/server
emacsclient: can't stat /tmp/emacs1000/server: Permission denied

[joaotavora]

But I thought your use case is to run code as a non-priviledged user and then stealthily wait for the user to use tramp and /sudo::, right? Emacsclient is fine for that