<div dir="ltr">I think the only thing they can do with that program is run it out of memory (unless there is a bug). All such code execution things built into read are, by default, disabled. You can avoid running out of memory with either custodian memory limits, or by just using the sandbox library.<div>
<br>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 9:46 PM, Michael Wilber <span dir="ltr"><<a href="mailto:mwilber@uccs.edu" target="_blank">mwilber@uccs.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With all these discussions about serialization safety in different<br>
languages (see <a href="http://news.ycombinator.com/item?id=5343704" target="_blank">http://news.ycombinator.com/item?id=5343704</a> for some<br>
commentary on clojure's default reader for example), I have to wonder:<br>
<br>
1. Is racket's (read) "safe" to use in an unsafe context?<br>
2. If not, how can I (read) a value from an untrusted port safely?<br>
<br>
For example (and perhaps as a friendly challenge), consider the<br>
following program that might be running on a public port:<br>
<br>
#lang racket<br>
(require mzlib/thread)<br>
<br>
(run-server 5553<br>
(lambda (in out)<br>
(let loop ()<br>
(print (read in) out)<br>
(newline out)<br>
(flush-output out)<br>
(loop)))<br>
30)<br>
<br>
How might an attacker be able to connect to this and evaluate arbitrary<br>
expressions? Using, say, the #s and #lang reader extensions might be<br>
interesting...<br>
<br>
If it is unsafe, how could we make this safe?<br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div>