Security flaw in Sandbox.safe when using box.ref

[senotrusov]

It is possible for sandbox to execute some code in a wild by modifying classes which is accessed via box.ref facility.

This can be done via:

1. defining new class/instance methods is referenced classes;
2. defining new singleton class/instance methods is referenced classes;
3. using class_eval/instance_eval/module_eval
4. and maybe with otherwise trick?

Possible workaround is to:

1. disable class instantiation by raising exception in a initialize method;

1a. (not tested) freeze instantiated object in the initialize method;

2. extend referenced class in the sandbox (not in the wild) with a following class methods: dup, clone, class_eval, instance_eval, module_eval - which all must raise some exception;

3. freeze referenced class in the sandbox (not in the wild).

I've attach a test script for this workaround. It test SandboxDataGateway? object for possible code execution. If you comment "box.do_workaround" call and SandboxDataGateway::initialize, you will see code like

SandboxDataGateway.new.instance_eval "puts `whoami`"

can be executed from the sandbox, giving access to 'system' call and stdout.

I am not sure - is it cover all security holes or not. Maybe I am not noticed something?

It would be great if why would fix it at some deeper level - in the sandbox C internals or so.

• ruby 1.8.6 (2007-03-13 patchlevel 0)
• patch for Ruby 1.8.6 from InstallingTheSandbox
• sandbox-0.4.tgz from InstallingTheSandbox

[senotrusov]

Can't attach file - server gives me 500 Internal server error.

Look for it at http://docs.google.com/Doc?id=ddvjqtf9_3g9m8pp