Out of curiosity, I made a patch to Clojure that causes the default value of
*read-eval* to be false instead of true, to see if any of the tests pass, and
to let other people try it out in case it breaks things that would be
surprising and/or disruptive. It is attached to this new ticket:
http://dev.clojure.org/jira/browse/CLJ-1153
I found this behavior from one of the unit tests included with Clojure. Does
it surprise anyone, or look like it would break something important?
% java -cp clojure.jar clojure.main
Clojure 1.5.0-master-SNAPSHOT
user=> '(list + 1 2 3)
(list + 1 2 3)
user=> (eval '(list + 1 2 3))
(#<core$_PLUS_ clojure.core$_PLUS_@11dfc8a0> 1 2 3)
user=> (eval (eval '(list + 1 2 3)))
RuntimeException EvalReader not allowed when *read-eval* is false.
clojure.lang.Util.runtimeException (Util.java:219)
The last expression evaluates to 6 when *read-eval* is true, with no exception.
Andy
On Jan 30, 2013, at 7:04 AM, Chas Emerick wrote:
> This is exactly the thread that I meant to start a couple of weeks ago.
> Thanks for giving me the kick in the pants, Takahiro. :-)
>
> What brought the issue to the fore for me:
>
> * a greatly increased interest in security issues due to my own work's
> requirements
> * the most recent arbitrary code execution issues that the Rails community
> has had to weather
> * Building and maintaining Friend (http://github.com/cemerick/friend) has
> gradually brought me into contact with a handful of suitably experienced
> people that have done security reviews (none formal or published, BTW) of the
> Clojure web stack.
>
> In each of the three times I've been fortunate to discuss those reviews with
> their instigators, the first thing that comes up is *read-eval*. Perhaps not
> surprising — we've all known that its default is an open barn door. The sole
> thread I could dig up that discusses this is
> http://groups.google.com/group/clojure/browse_frm/thread/1bd6b66b51406ec9?tvc=1,
> where the common refrain is simply "you should bind *read-eval* to false
> when reading data from unknown sources". Despite this not being news, recent
> events and certain changes in my foci have made it a newly-important issue,
> at least to me.
>
> Takahiro is exactly right that the growing usage of Clojure data / edn as a
> common serialization format for e.g. web service APIs makes the default of
> *read-eval* very, very relevant; IMO, despite any concerns re: breaking
> existing code. On that front, *read-eval* affects only the #= construction,
> a facility that is, IIRC, purposefully undocumented. This lack of
> documentation is good insofar as few people have used #=, but it has also
> left undocumented an implementation detail of the reader that ships with a
> dangerous default (see http://dev.clojure.org/jira/browse/CLJ-904).
>
> The advice and necessity to tighten up *read-eval* as "good practice" is a
> design fault. There are things that authors of certain key Clojure libraries
> can do to fix this up as a side effect of using those libraries, but it would
> obviously be ideal for Clojure/core to address the policy proactively.
> Otherwise, I'm certain that a time will come when people not steeped in
> Clojure arcana will be deploying vulnerable applications and services.
> Unfortunately, I suspect that time has long since arrived...we just don't
> (yet?) have the eyeballs and juice that the Rails community has to produce
> controversy.
>
> Cheers,
>
> - Chas
>
> On Jan 30, 2013, at 2:02 AM, Takahiro Hozumi wrote:
>
>> As more and more projects are using edn format for config,
>> communication and etc, I think that default value of *read-eval*,
>> which is true, is source of vulnerability such as recently reported
>> ring issue [1].
>> And I don't understand why read-string depends on *read-eval* instead
>> of argument.
>> I believe optional argument is more preferable.
>> What do you think?
>>
>> [1] Ring 1.0.3 / 1.1.7 released to fix security flaw
>> https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
