Comment by willismichael | Hacker News Reader

Comment by willismichael | Hacker News Reader

Parent Full thread

  ;; The particular issue of executing arbitrary Java constructors used
  ;; in the examples above no longer works in Clojure 1.5 when
  ;; *read-eval* is false.  Even so, you SHOULD NEVER USE
  ;; clojure.core/read or clojure.core/read-string for reading untrusted
  ;; data.  Use an edn reader or a different data serialization format.

From that comment it seems like the Java constructor loophole has been closed. With that gone, I don't understand why the reader is still dangerous. What am I missing?

I was wondering this too, and deliberately tried to break something using the clojure 1.5 reader with read-eval false. (Makes a change from building things all day!).

Result:

    user=> (binding [*read-eval* false] (read-string "``````````x"))
    OutOfMemoryError Java heap space  clojure.lang.RT.cons (RT.java:570)

There's a huge IRC log that explains the reasoning here. Mostly, it comes down to: you can't trust that libraries haven't changed read-eval back, which means that now instead of being assured that a certain fn can never be harmful, you would need to audit all libraries you use. It's the assumption itself (that read and read-string are safe) what makes it unsafe...

Reply on news.ycombinator.com