Andreas Fuchs' Journal: November 2004 Archives

Today, Kevin Rosenberg asked on IRC how to prevent code insertion when READing data from a string. A solution to that problem is binding *READ-EVAL* to NIL in code using READ.

Now, that got me wondering: which other security pitfalls are there in lisp? These are the other READ-related ones that came up in the discussion that followed:

• READ can intern symbols in packages other than the one you want it to (could lead to bugs further down in the application)

• READ (again) can produce self-referential objects (via #n=) that can make your application go into endless loops/recursion

• And of course, EVALing code that you get from the outside world is always a bad idea. As is writing it to a file and using COMPILE/LOAD.

So, any others? I’m sure there are. Having them collected in a central place would be a really good thing. Improved awareness of security problems might help prevent stuff like this bug in an intrusion detection system that did not set *READ-EVAL*.

A few months ago, Christophe suggested that autobuilding/autobenchmarking of CLisp would be nice to have in Boinkmarks. I tried, but couldn’t make it fit into the ugly bunch of shell scripts. This was when I decided to rewrite them in Common Lisp, and to add a nice web interface using araneida.

That is now finished. See the results at [[http://sbcl.boinkor.net/benchmark/]] old version, for contrast].

So, was it worth it? The rewrite doesn’t bring me that much closer to my goal of actually benchmarking CLisp; but adding that functionality is now much easier with the new CLOS-based protocol for building/caching/benchmarking implementation binaries (especially when compared to these ugly shell constructs). Another great advantage is that I now have a chance of understanding what I have written when I have to fix it in a few months.

Watch this space, there are a few benchmarking-related announcements waiting to be made in the near future (the release of the benchmarking tool, for one) (-: