Securely loading and running untrusted modules

Securely loading and running untrusted modules

[Richard Jones]

Suppose I wanted to set up a website where people could upload
untrusted .ml files and have them be compiled and run on my server.
(This would be used as an OCaml teaching tool).  The uploaded
"untrusted.ml" source files would be compiled on the server by
"ocamlc", then loaded using:

  Dynlink.init ();
  Dynlink.allow_only ["SafeAPI"];
  Dynlink.loadfile_private "untrusted.cmo"

where SafeAPI is a module which defines a safe, trusted subset of the
API where only Good Things are allowed.

I don't want the modules to be able to do Bad Things, where Bad Things
is stuff like:

* Reading and writing local files.
* Corrupting memory.
* Inserting executable code into memory.
* Executing arbitrary functions from the server.
* Denial of service (infinite loops, unlimited resource allocation).
* Making arbitrary network connections.
* (and so on ...)

To prevent unlimited resource allocation, I'm thinking of using
setrlimit(2) to limit the size of the server process (it would be a
pre-forked Apache server, so causing one process to hit its memory
limit does not constitute a denial of service attack).

To prevent infinite loops, starting an alarm(2) before loading the
module should kill the Apache process if it uses too much CPU time.

I'm fairly sure that the method above should cope with everything
barring bugs in the compiler and bugs in SafeAPI.

Am I thinking right?

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Securely loading and running untrusted modules

[Nicolas Cannasse]

> To prevent infinite loops, starting an alarm(2) before loading the
> module should kill the Apache process if it uses too much CPU time.
>
> I'm fairly sure that the method above should cope with everything
> barring bugs in the compiler and bugs in SafeAPI.
>
> Am I thinking right?
>
> Rich.

I think that current VM is optimized for speed and doesn't do more bytecode
checking than strictly necessary. That means that someone could forge some
bytecode file that would take control of the VM and then can call the whole
C api. Tricky, but feasible.
You might need to add load-time or runtime bytecode checks in order to
secure the VM.

Regards,
Nicolas Cannasse

Re: [Caml-list] Securely loading and running untrusted modules

[Richard Jones]

On Tue, Apr 05, 2005 at 09:55:32PM +0900, Nicolas Cannasse wrote:
> I think that current VM is optimized for speed and doesn't do more bytecode
> checking than strictly necessary. That means that someone could forge some
> bytecode file that would take control of the VM and then can call the whole
> C api. Tricky, but feasible.

I'm hoping that by compiling from source I'll avoid any bytecode
attacks.  Is there a way to generate faulty bytecode from a source
file?

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Securely loading and running untrusted modules

[Alex Baretta]

Richard Jones wrote:
> On Tue, Apr 05, 2005 at 09:55:32PM +0900, Nicolas Cannasse wrote:
> 
>>I think that current VM is optimized for speed and doesn't do more bytecode
>>checking than strictly necessary. That means that someone could forge some
>>bytecode file that would take control of the VM and then can call the whole
>>C api. Tricky, but feasible.
> 
> 
> I'm hoping that by compiling from source I'll avoid any bytecode
> attacks.  Is there a way to generate faulty bytecode from a source
> file?
> 
> Rich.

alex@alex:~$ ocaml
         Objective Caml version 3.08.2

# external pizza : 'a -> 'b = "%identity";;
external pizza : 'a -> 'b = "%identity"
# pizza 1 = "pasta";;
Segmentation fault


-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] Securely loading and running untrusted modules

[Richard Jones]

On Tue, Apr 05, 2005 at 04:09:05PM +0200, Alex Baretta wrote:
> alex@alex:~$ ocaml
>         Objective Caml version 3.08.2
> 
> # external pizza : 'a -> 'b = "%identity";;
> external pizza : 'a -> 'b = "%identity"
> # pizza 1 = "pasta";;
> Segmentation fault

Dynlink allows me to specify that modules can't use unsafe features,
so such declarations wouldn't be permitted.

A much more serious problem which I've just found is that _any_ module
(even the empty module) seems to require Pervasives.  Thus it seems to
be impossible to create any OCaml code which could be loaded by
Dynlink where Dynlink.allow_only does not specify "Pervasives".

rich@arctor:/tmp$ rm test_module.ml 
rich@arctor:/tmp$ touch test_module.ml
rich@arctor:/tmp$ ocamlc -c test_module.ml 
rich@arctor:/tmp$ ocamlobjinfo test_module.cmo 
File test_module.cmo
  Unit name: Test_module
  Interfaces imported:
        71f888453b0f26895819460a72f07493        Pervasives
        f7db4d58568a6e5a2cfe62ef59a52df1        Test_module
  Uses unsafe features: no
rich@arctor:/tmp$ ./test
Dynlink: no implementation available for Pervasives

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Securely loading and running untrusted modules

[Jacques Garrigue]

From: Richard Jones <rich@annexia.org>

> A much more serious problem which I've just found is that _any_ module
> (even the empty module) seems to require Pervasives.  Thus it seems to
> be impossible to create any OCaml code which could be loaded by
> Dynlink where Dynlink.allow_only does not specify "Pervasives".

This is why there is a compiler option named -nopervasives.
Basically your approach is right. If you compile the .ml files
yourself, this is safe, as long as there is no bug in the compiler.
Since there are certainly some, you have to follow messages on the
list and upgrade the compiler when needed, as for any security
issue...

Jacques Garrigue

Re: [Caml-list] Securely loading and running untrusted modules

[Virgile Prevosto]

Le 04/05/2005, à 03:17:46 PM, Richard Jones a écrit:
> A much more serious problem which I've just found is that _any_ module
> (even the empty module) seems to require Pervasives.  Thus it seems to

> rich@arctor:/tmp$ ocamlc -c test_module.ml 

Have you tried with the -nopervasives flag of ocamlc ? [of course this
supposes that your module does not rely on any function of the core
library, which is the case for the empty module]
~ [516]$ ocamlc -nopervasives -c test_module.ml
~ [517]$ ocamlobjinfo test_module.cmo
File test_module.cmo
  Unit name: Test_module
  Interfaces imported:
        f7db4d58568a6e5a2cfe62ef59a52df1        Test_module
  Uses unsafe features: no
-- 
E tutto per oggi, a la prossima volta
Virgile

Re: [Caml-list] Securely loading and running untrusted modules

[Daniel Bünzli]

> A much more serious problem which I've just found is that _any_ module
> (even the empty module) seems to require Pervasives.  Thus it seems to
> be impossible to create any OCaml code which could be loaded by
> Dynlink where Dynlink.allow_only does not specify "Pervasives".

Not sure but this seems possible with the -nopervasives option, see  
this thread :

<http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/ 
379d29454b8c48aa6e8a020c09fe0485.fr.html>

Daniel

Re: [Caml-list] Securely loading and running untrusted modules

[sejourne_kevin]

Jacques Garrigue a écrit :
> From: Richard Jones <rich@annexia.org>
> 
>>A much more serious problem which I've just found is that _any_ module
>>(even the empty module) seems to require Pervasives.  Thus it seems to
>>be impossible to create any OCaml code which could be loaded by
>>Dynlink where Dynlink.allow_only does not specify "Pervasives".
> 
> 
> This is why there is a compiler option named -nopervasives.
> Basically your approach is right. If you compile the .ml files
> yourself, this is safe, as long as there is no bug in the compiler.
> Since there are certainly some, you have to follow messages on the
> list and upgrade the compiler when needed, as for any security
> issue...
> 
> Jacques Garrigue
I can't find the way to use 'nopervasives' correctly, here is my test:
test.ml :
----------------
struct Pervasives = struct
	(* Here the code steal from pervasives.ml *)
end;;
open Pervasives;;
print_endline "hello world";;
----------------
[20:55:58 ~] ocamlc -nopervasives -o test test.ml
[20:56:25 ~] ./test
hello world
[20:56:28 ~]

strange....


Kévin.

Re: [Caml-list] Securely loading and running untrusted modules

[Jacques Garrigue]

From: sejourne_kevin <sejourne_kevin@yahoo.fr>
> I can't find the way to use 'nopervasives' correctly, here is my test:
> test.ml :
> ----------------
> struct Pervasives = struct
> 	(* Here the code steal from pervasives.ml *)
> end;;
> open Pervasives;;
> print_endline "hello world";;
> ----------------
> [20:55:58 ~] ocamlc -nopervasives -o test test.ml
> [20:56:25 ~] ./test
> hello world
> [20:56:28 ~]
> 
> strange....

Why?
If you copy all pervasives.ml, then you have access to all its
functionality.
The point is that you wouldn't be able to load this code dynamically
in safe mode.

Jacques Garrigue

Re: [Caml-list] Securely loading and running untrusted modules

[sejourne_kevin]

Jacques Garrigue wrote :
> Why?
> If you copy all pervasives.ml, then you have access to all its
> functionality.
> The point is that you wouldn't be able to load this code dynamically
> in safe mode.
> 
Sorry I did not see the function Dynlink.allow_unsafe_modules and its
doc yesterday.


Kévin.