* Helmut Eller <87d4oov6sk.fsf@lifebook.lan> Wrote on Thu, 17 Apr 2008 17:29:31 +0200: | * Madhu [2008-04-14 07:39+0200] writes: | |> SWANK-LOADER::SLIME-VERSION-STRING calls READ on the first form of the |> ChangeLog file without binding *READ-EVAL* to NIL, which is a potential |> security hole. This minor patch fixes that, to avoid future dire |> advisories... | | We even load user-init files. Isn't that a much more severe security | hole? User init files are lisp files created by the user and intended to be loaded at startup to customize the system. This is normal and not a security hole. However ChangeLog files are not lisp files, and not intended to be loaded by the system. The security hole is this: it is not a typical place that one would look for to audit code for safety. What is your excuse to keep this backdoor mechanism to allow loading of arbitrary code behind the user's back, assuming you can write the ChangeLog file? -- Madhu

* Helmut Eller <m2abjrg1y9.fsf@common-lisp.net> : Wrote on Fri, 18 Apr 2008 07:35:26 +0200: | * Madhu [2008-04-18 00:45+0200] writes: |> What is your excuse to keep this backdoor mechanism to allow loading of |> arbitrary code behind the user's back, assuming you can write the |> ChangeLog file? | | SLIME is supposed to be used in a secure environment and we don't make | any claims that SLIME is in any way secure. I don't see the point of | complicating the code for such non-problems. Sorry, I don't buy that reason. Binding *READ-EVAL* to NIL when calling READ on non-lisp source files is not complicated. The change I suggested in <m33appm1vm.fsf@robolove.meer.net> is one line: * ,[14 Apr 2008 11:09:09 +0530:] | -(defun slime-version-string () | +(defun slime-version-string (&aux *read-eval*) Besides, not only is it not complicating things, it is The Right Thing To Do. The code is doing the wrong thing if it does not bind reader variables before calling read. Let me repeat, binding *READ-EVAL* to NIL when calling READ on non-lisp source forms, when you are expecting DATA is the Right Thing To Do in lisp. In Common Lisp, this issue can be considered "equivalent" to buffer overflow in C. What you are defending is akin to defending the use of gets(3), and inviting buffer overflow problems, despite having beein informed that gets(3) is buggy and you should use fgets instead. I can't understand that attitude either! Of course you are the boss, feel free not to fix it :) -- Madhu (Now available for SLIME/CL consulting :-})

* Zach Beane <m37ierik0t.fsf@unnamed.xach.com> : Wrote on Mon, 21 Apr 2008 06:23:30 -0400: |> Besides, not only is it not complicating things, it is The Right Thing |> To Do. | | I don't think you should stop there. There is a dangerous file named | swank.lisp that is loaded by the lisp and slime.el is loaded by | emacs. An attacker thwarted by your ChangeLog fix could still modify | any of those files and take over your computer when you start slime! See <URL:http://permalink.gmane.org/gmane.lisp.slime.devel/7300> upthread in this thread where I explained why swank.lisp and slime.el are not a problem. TISLHFYP -- Madhu

Zach Beane <xach@xach.com> writes:

Madhu <enometh@meer.net> writes:

...

* Zach Beane <m37ierik0t.fsf@unnamed.xach.com> : Wrote on Mon, 21 Apr 2008 06:23:30 -0400: |> Besides, not only is it not complicating things, it is The Right Thing |> To Do. | | I don't think you should stop there. There is a dangerous file named | swank.lisp that is loaded by the lisp and slime.el is loaded by | emacs. An attacker thwarted by your ChangeLog fix could still modify | any of those files and take over your computer when you start slime!

See <URL:http://permalink.gmane.org/gmane.lisp.slime.devel/7300> upthread in this thread where I explained why swank.lisp and slime.el are not a problem.

I saw it. Count me as one of the unpersuaded.

AOL. We're talking about an attacker who can somehow modify or replace the Changelog file, but who cannot modify or replace swank.lisp or slime.el sitting right next to it in the same directory. An argument in support of binding read-eval to nil around read in this specific case could still be made: that an inexperienced coder browsing the slime sources would learn about *read-eval* that way. Rudi