Does call-with-default-reading-parameterization help? https://docs.racket-lang.org/reference/Reading.html?q=accept-compiled#%28def._%28%28lib._racket%2Fprivate%2Fmisc..rkt%29._call-with-default-reading-parameterization%29%29
The parameters you are seeing re: accepting -lang, -reader are for when the reader sees a reference to an extension that it can load and use. In that sense, code defined for that extension would execute so that the reader is prepared to process upcoming bytes. So if you are worried that the reader would execute code as a side-effect of reading, then yes, that can happen. Unsure what the #~ does, so I can't speak to that. Defining a procedure that flips off all parameters related to extensions is a good step, but I do not know if the linked example serves as a true "Deny All" equivalent. The docs make it seem like it does. Even so, I think there are other aspects to a zero-trust policy such as the values of `current-security-guard` and `current-code-inspector`... but you'll get to that. Using a different data format might work, but the library itself leverages the reader, then you still would care about enforcing these restrictions anyway. On 2/28/21 2:50 PM, Ryan Kramer wrote: > I want to send some Racket structs across a network. I know that I can use > prefab structs, serializable-structs, or even `eval` with a carefully curated > namespace. I was trying to think of security problems with the eval approach > and now I've become more afraid of `read` than I am of eval. And read seems > necessary for all 3 approaches. > > The first concern I thought of was cyclic data. My code assumes there are no > cycles; if an attacker can get me to process cyclic data my server will > probably loop forever or crash. This can be solved by setting > `read-accept-graph` to #f... I think. Right? (I guess another solution is > "you need to validate the input" which is fair, but it's easy to forget or > make a mistake.) > > This caused me to notice other `read-accept-***` parameters that looked scary > (-lang, -reader, -compiled). I don't know if there is an attack vector here, > but I felt safer turning them off also. > > Now I'm thinking that even if I can get it working safely today, Racket would > be well within its rights to make enhancements to the reader in the future. > So someday there might be new parameters that I would want to turn off to > preserve my definition of "safe", and I have to remember this when I upgrade. > > All this makes me think that `read` is not quite the right tool for the job. > But it's close. If there were a version of read that accepts nothing by > default and requires the caller to opt-in to everything they want, that would > probably be perfect. > > I could use JSON or XML, but that just seems silly when you have a Racket > client talking to a Racket server. > > Are my concerns founded? Are there any existing solutions? Thanks for any > advice. > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > [https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com?utm_medium=email&utm_source=footer). -- ~slg -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2d8bc7d7-30c0-7952-c4aa-81598998e9a0%40sagegerard.com.
