Re: [racket-users] Deserializing snips from untrusted input

2020-08-20 Thread 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


On Thu, Aug 20, 2020 at 2:29 PM Daniel Melcer  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 <
>> sorawe...@gmail.com> 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  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 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
 
 .

>>> --
>>> 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/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> 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 

Re: [racket-users] Deserializing snips from untrusted input

2020-08-20 Thread 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

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 <
> sorawe...@gmail.com> 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  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 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
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
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/d201725a-e043-4c31-975e-f0ff289982f4n%40googlegroups.com.


Re: [racket-users] Deserializing snips from untrusted input

2020-08-20 Thread 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


On Thu, Aug 20, 2020 at 2:08 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> 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  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 racket-users+unsubscr...@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
>> 
>> .
>>
> --
> 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/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com
> 
> .
>

-- 
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/CAL3TdOMHWqy1FM20OmbV1zB9x3WU%2BzDnbjguW%3D8PHfgfLgbmGw%40mail.gmail.com.


Re: [racket-users] Deserializing snips from untrusted input

2020-08-20 Thread 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.

On Thu, Aug 20, 2020 at 8:34 AM Daniel Melcer  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 racket-users+unsubscr...@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
> 
> .
>

-- 
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/CADcuegtnpb3h_JkDFmBdhiosJkz948ypkhmoj1vZc7vq5SAR0w%40mail.gmail.com.


[racket-users] Deserializing snips from untrusted input

2020-08-20 Thread 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

-- 
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/153d1c59-0343-4ed9-805b-2909499ec98fn%40googlegroups.com.