The Security Struggle with Lisp

Anil Somayaji July 29, 2021

Recently I read the transcript of Rich Hickey's 2017 talk on Effective Programs, which really was a talk about the benefits of Clojure (as a kind of Lisp and as its own thing). He made several points that resonated with me, including:

• Type systems are partial, incomplete specifications of program semantics, and so time invested in using complex type systems are at most a partial solution, one that can have a high cost.
• Strict type systems can cause problems when trying to express communication in heterogeneous, distributed systems.
• Programmers can be sucked in to solving puzzles that don't actually help address the problem at hand.

But what struck me about this essay was that he discussed communication and distributed systems without making a single reference to security or trust. And this got me thinking.

I've long been a fan of Lisp and Lisp-like systems, and when I develop in other languages (which is almost always) I find myself trying to use techniques that I first learned with Lisp and Scheme. However, in the world of security, the values that are celebrated by Lisp-like systems are denigrated if not outright rejected. For example, many security practitioners have a strong aversion to treating code as data, because then attackers can inject data and turn it into code, subverting the security properties of the system. As a security measure, data pages in process memory are no-execute by default nowadays and code pages are read only. Systems that want to treat data as code, such as just-in-time compilers, must constantly switch pages between being writable and executable. Anything that is truly Lisp-like, however, treats code as just another data structure to be manipulated by code and even includes facilities for dynamically changing the semantics of code on the fly.