4 ms·

Lately I began to study information security in more detail. Isn't the "code is data" philosophy of common lisp a nightmare for a web server?

SamReidHughes 12y ago
The web server isn't calling "eval," is it?
sanxiyn 12y ago
No. Interpreting untrusted data as code can be pretty dangerous. Lisp is usually about interpreting trusted data as code, which is no problem.
eudox 12y ago
As a fun aside: The Symbolics network code called READ on untrusted data on more than one occasion.
- lispm 12y ago
  Have you seen that code? I just searched through sys:network; and sys:ip-tcp; in Genera 8.3 and the only use of READ was in an Eval server.
  - eudox 12y ago
    I read it on a tweet somewhere.
    - lispm 12y ago
      Then it must be true.
  - ScottBurson 12y ago
    I distinctly recall, c. 1983, that 'read' was called as part of the NFILE protocol. The reason I noticed was that I had created a package that did not use 'lisp:', and therefore 'nil' was no longer 'lisp:nil', which broke the NFILE client. Maybe this got fixed sometime between then and 8.3. (Or maybe NFILE was ripped out altogether?) I also recall that Jeff Schiller found some remote vulnerabilities. I don't know if they involved 'read', but they certainly could have. Again, this was long before 8.3.
    - lispm 12y ago
      Are you sure? There is a READ command in NFILE, but there are no obvious calls to READ. Symbols could have been created or looked up by other means...
hga 12y ago
Classically, "code is data" is used upfront, in creating macros that manipulate Lisp code as data, before sending the result to the interpreter or compiler like normal functions and data. Ideally you develop your own Domain Specific Language that provides power in expression and execution for what you're trying to do. As implied in other answers in the subthread, nowhere in this paradigm does random input data get treated as something that can safely be executed. READ in Lisp Machines is mentioned because reader macros like #. allow data in the form being read to be evaluated, which in this domain is an obvious big no-no. As early as 1983, I think earlier, it was recognized that things like eval servers were a bad idea if accessible by the outside world.
- bayesianhorse 12y ago
  So, I am really just a beginner. To me it seems to be the case that attackers may find a way to break out of a particular data processing instruction and execute arbitrary lisp code. If you say, this can't be so, you may well be right...
  - hga 12y ago
    As I understand it, unless you're using a Lisp with an reader macro that calls eval, or your code calls eval, and you allow arbitrary input into that code while running vs. loading/compiling, it's just not going to happen.
avodonosov 12y ago
No

SamReidHughes 12y ago

The web server isn't calling "eval," is it?

sanxiyn 12y ago

No. Interpreting untrusted data as code can be pretty dangerous. Lisp is usually about interpreting trusted data as code, which is no problem.

eudox 12y ago

As a fun aside: The Symbolics network code called READ on untrusted data on more than one occasion.

lispm 12y ago
Have you seen that code? I just searched through sys:network; and sys:ip-tcp; in Genera 8.3 and the only use of READ was in an Eval server.
- eudox 12y ago
  I read it on a tweet somewhere.
  - lispm 12y ago
    Then it must be true.
- ScottBurson 12y ago
  I distinctly recall, c. 1983, that 'read' was called as part of the NFILE protocol. The reason I noticed was that I had created a package that did not use 'lisp:', and therefore 'nil' was no longer 'lisp:nil', which broke the NFILE client. Maybe this got fixed sometime between then and 8.3. (Or maybe NFILE was ripped out altogether?) I also recall that Jeff Schiller found some remote vulnerabilities. I don't know if they involved 'read', but they certainly could have. Again, this was long before 8.3.
  - lispm 12y ago
    Are you sure? There is a READ command in NFILE, but there are no obvious calls to READ. Symbols could have been created or looked up by other means...

hga 12y ago

Classically, "code is data" is used upfront, in creating macros that manipulate Lisp code as data, before sending the result to the interpreter or compiler like normal functions and data. Ideally you develop your own Domain Specific Language that provides power in expression and execution for what you're trying to do. As implied in other answers in the subthread, nowhere in this paradigm does random input data get treated as something that can safely be executed. READ in Lisp Machines is mentioned because reader macros like #. allow data in the form being read to be evaluated, which in this domain is an obvious big no-no. As early as 1983, I think earlier, it was recognized that things like eval servers were a bad idea if accessible by the outside world.

bayesianhorse 12y ago
So, I am really just a beginner. To me it seems to be the case that attackers may find a way to break out of a particular data processing instruction and execute arbitrary lisp code. If you say, this can't be so, you may well be right...
- hga 12y ago
  As I understand it, unless you're using a Lisp with an reader macro that calls eval, or your code calls eval, and you allow arbitrary input into that code while running vs. loading/compiling, it's just not going to happen.

avodonosov 12y ago