From: Jan Svitok <jan.svitok@...>
Date: 2007-01-08T02:49:03+09:00
Subject: Re: mod_ruby security

On 1/6/07, Matteo Cavalleri <shiva.brahma@tiscali.invalid> wrote:
> I'm learning ruby and I'm currently enjoing reinventig the wheel just
> for the sake to understand how things work under ruby and mod_ruby.
> well, mod_ruby faq says:
>
> "But on the other side, different scripts run using the same Ruby
> interpreter, so a malicious script can change the behavior of the other
> scripts."
>
> what does it mean more precisely? what's the kind of access one script
> may have to other scripts' variables/objects/classes? I'm sorry if the
> question is old but my searches on the web weren't succesful...

[Note: I have not studied mod_ruby internals. I'm building on the
statement that all scripts run in the same interpreter]

There are several things a script can do:

1. call your objects' methods - enumerate all objects (via
ObjectSpace.each_object), methods (via Object#methods) and call
private methods via Object#send. The similar for variables and
constants. Call any code in the context of the object either via
adding new method or using instance_eval

2. modify your classes/objects - the classes are open, trace/debug
your code via set_trace_func and/or rdebug/breakpoint etc.

3. see your source code using __SCRIPT_LINES

4. the other script runs with the same privileges as your script, so
it sees the same files - configs, data, etc.

In summary, the script can do almost anything security-wise.

> anyway... let's suppose I've my brand new application with its database
> class which opens a connection to the db with the correct user and
> password, and a session class wich keeps track of user sessions, login,
> etc. then I put my program on a web hosting service
>
> how should I write my classes so that a malicious script running on the
> same web hosting service can't access my db or get an authenticated
> session by poking with my classes?

This is usually solved by not using mod_ruby ;-) The other way running
your script using webrick/mongrel/mod_fcgi within its own interpreter
and in case of mongrel/webrick reverse proxying them with an optional
load balancer (apache/pond/lighttpd/ngix/...) That way, each script
has its own interpreter running under different user. (From the above
the optimal one seems to be a bunch of mongrels behind something -
apache/pond/... - see mongrel.rubyforge.org)

_why was working on a sandbox that would allow separating code within
one interpreter, but I don't know how far has he got (see
code.whytheluckystiff.net)

Finally something can be done using $SAFE_MODE, although that's not a
fix for all of the above problems.

Problem with the above solutions might be that the webhosting provider
has to install them (unless you have a dedicated host or a VPS).
Fortunatelly many hostings provide mongrel&co for their clients.