Remix.run Logo
medo-bear 3 days ago

It is (should be) well known that macros, lisp ones and even less capables ones from other languages, are problematic for security. I think a good temporary mitigation to this in Emacs is scanning 3rd party .el files for macros. If there is a macro present give trust warning and offer decreased functionality if untrusted

VyseofArcadia 3 days ago | parent | next [-]

Macros are pretty ubiquitous in lisp. This would result in a trust warning for pretty much every .el file. I think this would go about as well as Windows Vista UAC pop ups or State of California cancer warnings. If everything is dangerous, nothing is.

medo-bear 3 days ago | parent | next [-]

The qualifying term is 'trusted'. If you are running an application like emacs you damn sure better trust it. It's like running Windows and saying you don't trust it.

AS for macros in lisp, they are not as ubiquitous as it might seem to an outsider. I write lisp professionally. I write one macro a month, if that, and often I rewrite it as a function afterwards. Saying that macros are ubiquitous in lisp is a meme. To most lispers macros are last resort

deng 3 days ago | parent | prev [-]

If I understand this correctly, this exploit only works with macros that evaluate at least one of their arguments, otherwise no code is actually run. These kind of macros are not that common. I guess one possible fix would be to mark these kind of macros as potentially dangerous and do not expand them automatically for things like code completion and such.

SoftTalker 3 days ago | parent | prev [-]

This is what Word and Excel (used to?) do when opening (or was it previewing?) .doc and .xls files in email. Macros, if present, were disabled.

kazinator 2 days ago | parent [-]

Microsoft office macros are not Lisp macros.

When you load a Lisp source code file, each of the forms and that file is read and executed.

You know like pretty much any scripting language.

You don't need a macro to perpetrate damage.

Bash doesn't have macros. yet it's a very bad idea to do this:

  wget https://url | bash
Lisp macros execute even when a file is not being executed but only compiled. What that means is that you have to trust a file in order to compile it because by doing so you're running it.

Besides compiling any other tooling which expands macros is vulnerable to execution. As we can see in this article, there our situations when if you're working with list code inside Emacs, it will expand the macros.

If you were going to blindly run the code anyway, that makes no difference. But developers often look at untrusted source code with no intention to run it and not expecting to do anything harmful just by sitting in their editor.

In principle Lisp macros could be sandboxed. The vast majority of macros do not need to do any system access. They just look at their argument code pieces and calculate a new piece of code, without any side effects or accessing anything in the system.