I believe that the "other ways to cause harm" that mention applies here, but this is the docs that explain the thing I'm talking about:
https://docs.racket-lang.org/gui/editor-overview.html?q=snip-class#%28part._editorsnipclasses%29 It would require the attacker put the file on the disk in a collection and then this would trigger running that code. There are other ways to trigger running code (e.g., starting up DrRacket) if the attacker can write to the filesystem into a collection, tho. Robby On Thu, Aug 20, 2020 at 2:29 PM Daniel Melcer <[email protected]> wrote: > To make sure I'm understanding correctly, as long as the code verifies > that the given snipclass is in (get-the-snip-class-list), it should be > relatively safe? So the only way that the user would run malicious code in > this case is if they installed a malicious package first, in which case > there are easier ways to cause harm. > > OTOH, when using the load-file method, the dynamic-require could be an > issue if a theoretical attacker put a .rkt file at a known path and the > input to load-file refers to that path. > > Daniel > > On Thursday, August 20, 2020 at 3:12:00 PM UTC-4 Robby Findler wrote: > >> The issue I mention in 157 is different than this one. >> >> In this situation, the snipclass needs to be installed somehow before its >> code will be loaded, but that installation can happen by a require >> (triggered by the opening of that snip). So it may be that you have code >> installed in a collection that you do not trust and unmarshalling a snip >> may load that code. >> >> That said, in the code below, I don't think this is happening. In >> particular, the way that untrusted code may be loaded is because the name >> of the snipclass follows a specific format and the editor itself is going >> to do the require. >> >> In short, you can treat the `load-file` method of editor<%> as possibly >> doing a dynamic-require. This may or may not be a problem, of course. >> >> (At least I think that that's the only thing here. I may be forgetting >> something?) >> >> Robby >> >> >> On Thu, Aug 20, 2020 at 2:08 PM Sorawee Porncharoenwase < >> [email protected]> wrote: >> >>> I don't know much about this specific case, but see Robby's comment >>> about how "DrRacket can run user (untrusted) code in certain situations" at >>> https://github.com/racket/gui/issues/157. A concrete problem I found is >>> that you can have a snip running `struct->vector` and it will successfully >>> extract private fields of that struct value, even though it won't be able >>> to if you do that in normal circumstances. >>> >>> On Thu, Aug 20, 2020 at 8:34 AM Daniel Melcer <[email protected]> wrote: >>> >>>> There are some well-known vulnerabilities that are a result of >>>> deserializing untrusted inputs. Are editor snips restrictive enough that >>>> their deserialization is safe? After all, they are already loaded when a >>>> file is opened in DrRacket, and a file on the disk may originate from an >>>> untrusted source. In particular, I would be doing something like this >>>> (snip-class-name, bytes, and snip-pos are from an untrusted source). The >>>> whole thing will be wrapped in an exception handler: >>>> >>>> (define snip-class (send (get-the-snip-class-list) find >>>> snip-class-name)) ; Also handle case where this returns #f >>>> (define bytes-base-in (make-object editor-stream-in-bytes-base% >>>> bytes)) >>>> (define editor-stream-in (make-object editor-stream-in% >>>> bytes-base-in)) >>>> (define new-snip (send snip-class read editor-stream-in)) >>>> (send text insert new-snip snip-pos) >>>> >>>> Daniel >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-users/153d1c59-0343-4ed9-805b-2909499ec98fn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/racket-users/153d1c59-0343-4ed9-805b-2909499ec98fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-users/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com >>> <https://groups.google.com/d/msgid/racket-users/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/d201725a-e043-4c31-975e-f0ff289982f4n%40googlegroups.com > <https://groups.google.com/d/msgid/racket-users/d201725a-e043-4c31-975e-f0ff289982f4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOM%2BXp6YRAvzYjEiCj_wMdQoHnsabEDC8t6AKX5fDLhEdQ%40mail.gmail.com.
