* Psyntax security hole prevents secure sandboxing in Guile @ 2012-05-06 18:17 Mark H Weaver 2012-05-07 11:58 ` Noah Lavine 2012-05-07 16:31 ` Ludovic Courtès 0 siblings, 2 replies; 7+ messages in thread From: Mark H Weaver @ 2012-05-06 18:17 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-06 18:17 Psyntax security hole prevents secure sandboxing in Guile Mark H Weaver @ 2012-05-07 11:58 ` Noah Lavine 2012-05-07 16:31 ` Ludovic Courtès 1 sibling, 0 replies; 7+ messages in thread From: Noah Lavine @ 2012-05-07 11:58 UTC (permalink / raw) To: Mark H Weaver; +Cc: guile-devel 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-06 18:17 Psyntax security hole prevents secure sandboxing in Guile Mark H Weaver 2012-05-07 11:58 ` Noah Lavine @ 2012-05-07 16:31 ` Ludovic Courtès 2012-05-07 17:44 ` Mark H Weaver 1 sibling, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2012-05-07 16:31 UTC (permalink / raw) To: guile-devel 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-07 16:31 ` Ludovic Courtès @ 2012-05-07 17:44 ` Mark H Weaver 2012-05-07 18:25 ` Noah Lavine 2012-05-08 14:41 ` Ludovic Courtès 0 siblings, 2 replies; 7+ messages in thread From: Mark H Weaver @ 2012-05-07 17:44 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-07 17:44 ` Mark H Weaver @ 2012-05-07 18:25 ` Noah Lavine 2012-05-07 20:10 ` Andreas Rottmann 2012-05-08 14:41 ` Ludovic Courtès 1 sibling, 1 reply; 7+ messages in thread From: Noah Lavine @ 2012-05-07 18:25 UTC (permalink / raw) To: Mark H Weaver; +Cc: Ludovic Courtès, guile-devel > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-07 18:25 ` Noah Lavine @ 2012-05-07 20:10 ` Andreas Rottmann 0 siblings, 0 replies; 7+ messages in thread From: Andreas Rottmann @ 2012-05-07 20:10 UTC (permalink / raw) To: Noah Lavine; +Cc: Mark H Weaver, Ludovic Courtès, guile-devel 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/> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Psyntax security hole prevents secure sandboxing in Guile 2012-05-07 17:44 ` Mark H Weaver 2012-05-07 18:25 ` Noah Lavine @ 2012-05-08 14:41 ` Ludovic Courtès 1 sibling, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2012-05-08 14:41 UTC (permalink / raw) To: guile-devel 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-05-08 14:41 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-06 18:17 Psyntax security hole prevents secure sandboxing in Guile Mark H Weaver 2012-05-07 11:58 ` Noah Lavine 2012-05-07 16:31 ` Ludovic Courtès 2012-05-07 17:44 ` Mark H Weaver 2012-05-07 18:25 ` Noah Lavine 2012-05-07 20:10 ` Andreas Rottmann 2012-05-08 14:41 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).