------ art_2823_18011586.1132750074124 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/11/05, why the lucky stiff <ruby-core / whytheluckystiff.net> wrote: > > I've been playing with Ruby sandboxing alot over the past several > weeks. I've been using remove_const and redefinitions of classes to > limit Ruby rather than $SAFE. I want to offer an interpreter which can > be scripted without needing to learn tainting and still giving the > ability to `eval'. > > Here are the assumptions: > 1. The filesystem is chroot'd or, better yet, a virtual filesystem > implemented in Ruby memory. (Like MockFS.) > 2. Scripts will be monitored for CPU usage and consuming processes will > be killed. > 3. STDERR, STDIN and STDOUT are attached to the user's input and output > (the browser). > 4. The following constants are removed from Object: Continuation, GC, > ObjectSpace, Process. > 5. The following methods are removed or redefined in Kernel: (backtick), > abort, autoload, autoload?, exec, exit, exit!, getc, gets, fork, load, > readline, readlines, require, select, syscall, system, test. > 6. As a part of #1, the following class are redefined to prevent them > from accessing the actual filesystem: File, FileTest, Dir, DBM, > File::Stat. > 7. All communication to the interpreter is done through a UNIXServer > socket, like this: > > s = UNIXServer.open( socket_path ) > # .. removal of all constants (including UNIXServer), loading of libs > while true > Thread.start( s.accept ) do |s| > if cmd = s.gets > s.write eval(cmd) > s.close > end > end > end > > It's a bit more complicated than this, but you get the idea. > > My questions are three: > 1. Are removed constants and methods available elsewhere in the > interpreter? > 2. Could this be distilled into a general practice, as standard as $SAFE? > 3. In general, what am I overlooking? > > _why > > > The new ideas keep coming, but, for some reason, I have to hit send to get the next one ;) I blame Wikipedia editing. Do you want to motivate those who see a secured system and then spend sleepless weeks finding a crack ? Do you want some script kiddie to try script after script until one works on a real hole ? No ? Fake an unsecured system. No challenge for those who like challenges. Wasted effort by those who like petty destruction and one-upping stupid sysadmins (let them waste time cracking your authentic-looking /etc/shadow file because an idiot like you ran a Ruby interpreter as root). This doesn't increase your actual security, since it's merely obfuscation, but it has its charms. After all, a fly that looks like a bee can't really sting, but people still back away from it. For instance, there was the time when a script-kiddie told me to use some paste-this-code-to-get-IRCop backdoor. His commands worked on me the first few minutes, because I manually did whatever the innocuous commands said for kicks. After that, even intermittent failures (over TCP !) and strange misspellings of what he had typed could not shake his belief that he was in control of my computer. He certainly didn't try any other (possibly workable) avenues to control my computer, not that I was worried. A side benefit was that the time he wasted on me was not time he wasted on the less-informed. Faking has an additional side benefit of changing the cracking behavior of people who know about 'sandbox'. Without faking, they can see instantly when they've found a break: secured methods look secured (perhaps they give some error) and unsecured leftovers look unsecured (they don't give an error), so they can test 250 ways of doing something until they get a different response. With faking, it requires many more brain cells to tell the secure from the unsecure. To further muddy the waters, use TIMTOWTDI to your advantage, as I do in this badly contrived example : '5'.to_i => 3984234 '5'.to_i => 3984234 '5'.to_i => 3984234 '5'.to_i => 3984234 Integer(5) => -53 Integer(5) => -53 Integer(5) => -53 Integer(5) => -53 unsecured_conversion_thing('5') => 5 unsecured_conversion_thing('5') => 5 unsecured_conversion_thing('5') => 5 unsecured_conversion_thing('5') => 5 Now the sucka foo can't use a known-faked result and simply scan for anything that differs. Everything differs. He also can't check for multiple calls of the same method giving random results; the random result is either pregenerated or cached. This is especially (only?) effective on methods that give different results on different systems, like directory-listing methods. ------ art_2823_18011586.1132750074124--