<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On 7 Mar 2010, at 05:45, Elliott Slaughter wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<div><br></div><div>I would like to use cl-store to serialize messages sent over a network connection and am wondering if cl-store has any known security issues. I know, for example, that pickle in python can be used to execute arbitrary code when deserializing an object [1]. Does cl-store have any obvious issues like this?<br clear="all"></div></blockquote><div><br></div><div>Hi Elliot,</div><div><br></div><div> All deserialization in the default backend is done via read-byte which is then fed into custom constructors so I would be</div><div> quite confident in saying that cl-store isn't vulnerable to arbitrary code execution.</div><div><br></div><div> One possible source of concern would be hash-table & function restoration; A carefully crafted data stream could create a data </div><div> structure with a malicious function. As an example if you had the following function defined in your image</div><div><br></div><div>(defun clear-all-data (a b)</div><div> ... ; some code which deletes all data from your database</div><div>)</div><div><br></div><div>then a stream could be crafted which, when loaded, would create a hash-table with this function as the hash-table-test.</div><div>If your lisp allows arbitrary hash table tests then this would run clear-all-data when using the hash-table.</div><div><br></div><div>If you are concerned about this, a work around would be to create a new backend which extends the cl-store-backend</div><div>and override the hash-table restore to only allow symbols and/or only allow a certain set of tests.</div><div><br></div><div>Additionally CLISP has support for restoration of arbitrary closures which would allow the same attack but without the </div><div>requirement that the function be predefined. If you are using CLISP I would suggest extending the default backend</div><div>and using the following definitions for function storing and restoring.</div><div><br></div><div><div>(defstore-cl-store (obj function stream)</div><div> (output-type-code +function-code+ stream)</div><div> (store-object (get-function-name obj) stream))</div><div><br></div><div>(defrestore-cl-store (function stream)</div><div> (fdefinition (restore-object stream)))</div><div><br></div><div><br></div></div><div><br></div><div> To my knowledge the only other vulnerabilities would revolve around uses of eval, read or read-from-string which cl-store </div><div> does not use.</div><div><div><br></div><div><br></div><div>Regards,</div><div> Sean.</div></div><div><br></div><br><blockquote type="cite"><div>
<br></div><div>Thanks.</div><div><br></div><div>[1] <a href="http://nadiana.com/python-pickle-insecure">http://nadiana.com/python-pickle-insecure</a></div><div><br>-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br>
</div>
_______________________________________________<br>cl-store-devel mailing list<br><a href="mailto:cl-store-devel@common-lisp.net">cl-store-devel@common-lisp.net</a><br>http://common-lisp.net/cgi-bin/mailman/listinfo/cl-store-devel<br></blockquote></div><br></div></body></html>