Deserializing snips from untrusted input

[Daniel Melcer]

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

[Sorawee Porncharoenwase]

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.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/153d1c59-0343-4ed9-805b-2909499ec98fn%40googlegroups.com.

[Robby Findler]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com.

[Daniel Melcer]

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

[Robby Findler]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/d201725a-e043-4c31-975e-f0ff289982f4n%40googlegroups.com.