Psyntax security hole prevents secure sandboxing in Guile

Psyntax security hole prevents secure sandboxing in Guile

[Mark H Weaver]

Hello all,

Every once in a while someone asks about secure sandboxing with Guile,
and generally the response is that it should be fairly easy, by creating
a module with carefully selected bindings, but there's nothing ready
"out of the box".

I just realized that psyntax has a security hole that prevents secure
sandboxing, and wanted to post this fact before it was forgotten.

The problem is that psyntax accepts syntax-objects in the input, and
syntax-objects are simply vectors (or sexps containing vectors).
Therefore, it is always possible to _forge_ syntax-objects that refer to
arbitrary bindings in arbitrary modules, even if the usual bindings of
'@' and '@@' are not available.

In particular (although this is an internal implementation detail that
you cannot rely upon!) in Guile 2.0 the following two expressions are
treated equivalently:

  (@@ (ice-9 popen) open-pipe*)

  #(syntax-object open-pipe* ((top)) (hygiene ice-9 popen))

I don't think we can plug this hole until 2.2.

     Mark

Re: Psyntax security hole prevents secure sandboxing in Guile

[Noah Lavine]

That is an interesting problem. It would be nice to have sandboxing.

I'm writing to point out that there has been an attempt to make
"out-of-the-box" sandboxing work. The modules (ice-9 safe) and (ice-9
safe-r5rs) should be sandboxed environments, I think. (I encountered
them while looking for undocumented modules.) There's also the (ice-9
null) module, which gives an environment with only the basic syntax
and no procedures at all.

Noah

On Sun, May 6, 2012 at 2:17 PM, Mark H Weaver <mhw@netris.org> wrote:
> Hello all,
>
> Every once in a while someone asks about secure sandboxing with Guile,
> and generally the response is that it should be fairly easy, by creating
> a module with carefully selected bindings, but there's nothing ready
> "out of the box".
>
> I just realized that psyntax has a security hole that prevents secure
> sandboxing, and wanted to post this fact before it was forgotten.
>
> The problem is that psyntax accepts syntax-objects in the input, and
> syntax-objects are simply vectors (or sexps containing vectors).
> Therefore, it is always possible to _forge_ syntax-objects that refer to
> arbitrary bindings in arbitrary modules, even if the usual bindings of
> '@' and '@@' are not available.
>
> In particular (although this is an internal implementation detail that
> you cannot rely upon!) in Guile 2.0 the following two expressions are
> treated equivalently:
>
>  (@@ (ice-9 popen) open-pipe*)
>
>  #(syntax-object open-pipe* ((top)) (hygiene ice-9 popen))
>
> I don't think we can plug this hole until 2.2.
>
>     Mark
>

Re: Psyntax security hole prevents secure sandboxing in Guile

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> Every once in a while someone asks about secure sandboxing with Guile,
> and generally the response is that it should be fairly easy, by creating
> a module with carefully selected bindings, but there's nothing ready
> "out of the box".
>
> I just realized that psyntax has a security hole that prevents secure
> sandboxing, and wanted to post this fact before it was forgotten.

There are many other holes, such as the fact that ‘@@’ is compiled to
the ‘toplevel-ref’ instruction, which can search inside modules.

> The problem is that psyntax accepts syntax-objects in the input, and
> syntax-objects are simply vectors (or sexps containing vectors).

I agree it would be nice to fix eventually, using structs, but it takes
more than this to allow for “secure sandboxing”.

Thanks,
Ludo’.

Re: Psyntax security hole prevents secure sandboxing in Guile

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Every once in a while someone asks about secure sandboxing with Guile,
>> and generally the response is that it should be fairly easy, by creating
>> a module with carefully selected bindings, but there's nothing ready
>> "out of the box".
>>
>> I just realized that psyntax has a security hole that prevents secure
>> sandboxing, and wanted to post this fact before it was forgotten.
>
> There are many other holes, such as the fact that ‘@@’ is compiled to
> the ‘toplevel-ref’ instruction, which can search inside modules.

'@@' can be rebound, so that its default binding is no longer available:

   scheme@(guile-user)> (@@ (ice-9 popen) open-pipe*)
   $1 = #<procedure open-pipe* (mode command . args)>
   scheme@(guile-user)> (define @@ 2)
   scheme@(guile-user)> (@@ (ice-9 popen) open-pipe*)
   ;;; <stdin>:3:4: warning: possibly unbound variable `ice-9'
   ;;; <stdin>:3:4: warning: possibly unbound variable `popen'
   ;;; <stdin>:3:0: warning: possibly unbound variable `open-pipe*'
   <unnamed port>:3:4: In procedure #<procedure 103199b0 at <current input>:3:0 ()>:
   <unnamed port>:3:4: In procedure module-lookup: Unbound variable: ice-9
   
   Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
   scheme@(guile-user) [1]> 

In the past, some of us (including me) have suspected that by creating a
module with all dangerous bindings removed (including '@' and '@@'), one
could create a secure sandbox in Guile.  Sadly, that is not the case.

>> The problem is that psyntax accepts syntax-objects in the input, and
>> syntax-objects are simply vectors (or sexps containing vectors).
>
> I agree it would be nice to fix eventually, using structs, but it takes
> more than this to allow for “secure sandboxing”.

Can you think of anything else that would need to be fixed, besides this
problem with forgeable syntax-objects?

    Thanks,
      Mark

Re: Psyntax security hole prevents secure sandboxing in Guile

[Noah Lavine]

> Can you think of anything else that would need to be fixed, besides this
> problem with forgeable syntax-objects?

It depends how much of a sandbox you're thinking of, but I'd like to
make sure that the untrusted code didn't go into an infinite loop,
which means either putting it in a separate process or having a timer
that would stop it after a deadline. Also you'd have to make sure that
you didn't run any procedure returned by the untrusted code, for the
same reason.

Also, what if the untrusted code allocated a lot of memory? I suppose
you could depend on that all being garbage-collected after it
finished, but you'd have to be prepared to handle out-of-memory errors
while it was running.

It might be easiest to just put it in a separate process, although
that would make communication harder.

Noah

Re: Psyntax security hole prevents secure sandboxing in Guile

[Andreas Rottmann]

Noah Lavine <noah.b.lavine@gmail.com> writes:

>> Can you think of anything else that would need to be fixed, besides this
>> problem with forgeable syntax-objects?
>
> It depends how much of a sandbox you're thinking of, but I'd like to
> make sure that the untrusted code didn't go into an infinite loop,
> which means either putting it in a separate process or having a timer
> that would stop it after a deadline. Also you'd have to make sure that
> you didn't run any procedure returned by the untrusted code, for the
> same reason.
>
> Also, what if the untrusted code allocated a lot of memory? I suppose
> you could depend on that all being garbage-collected after it
> finished, but you'd have to be prepared to handle out-of-memory errors
> while it was running.
>
> It might be easiest to just put it in a separate process, although
> that would make communication harder.
>
Racket has a facility that achieves sandboxing (with the above property
of CPU and RAM usage bounds), i believe:

http://docs.racket-lang.org/reference/Sandboxed_Evaluation.html

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: Psyntax security hole prevents secure sandboxing in Guile

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Every once in a while someone asks about secure sandboxing with Guile,
>>> and generally the response is that it should be fairly easy, by creating
>>> a module with carefully selected bindings, but there's nothing ready
>>> "out of the box".
>>>
>>> I just realized that psyntax has a security hole that prevents secure
>>> sandboxing, and wanted to post this fact before it was forgotten.
>>
>> There are many other holes, such as the fact that ‘@@’ is compiled to
>> the ‘toplevel-ref’ instruction, which can search inside modules.
>
> '@@' can be rebound, so that its default binding is no longer available:

Right.  However, code compiled outside the sandbox, with the real ‘@@’,
does have that ‘toplevel-ref’ in it.

> Can you think of anything else that would need to be fixed, besides this
> problem with forgeable syntax-objects?

CPU/memory resource revocation, the ability to pass immutable references
to existing objects (variables, vectors, etc.), and mediated access to
OS resources such as file descriptors.

Also, a simple way to create a new module hierarchy based on an existing
one is needed.  To goal would be to make it easy, for instance, to
invoke code within a module hierarchy that lacks (system foreign), has
no POSIX procedures in (guile), and where (set! + -) would not affect
the outside world.  All this is currently doable, but a high-level API
to do it is lacking.

Thanks,
Ludo’.