Try Ruby is back online

Greetings,

Some of you may have noticed that Try Ruby was down this weekend. It is
now
back up.

In the downtime, I discovered several things.

Try Ruby is not compatible with 1.9.2-*. I am still looking in to why
this
is the case, but ruby 1.9.2 will not execute tryruby.rb.
I am hoping that I am wrong about this, but every time I try to use
1.9.2 it
is unable to find tryruby.rb – even through it is in the same directly
as
irb.cgi.

Second, the gem sexp does not appear to be compatible with
sexp_processor.
This is particularly frustrating when ruby_parser continues to complain
about sexp not being found, when in fact what it is looking for is
sexp_processor.

Third, I tried to put try ruby into a rails app. This worked
fantastically
well from webrick, but failed miserably with passenger.
Thus, it is deployed rails-less again. The issue with passenger was that
it
could not find Rack gem, when that gem was in fact installed.

The reason why try ruby was upgraded in the first place was due to an
exploit that was discovered by Adrian.

It turned out that running the following code:

begin; q = -> {echo hi}.(); rescue Exception => e; p e; end; p q
“hi\n”

worked. ouch!

This is particular egregious due to the fact that it allowed someone to
change the value of $SAFE.
The reason for this appears to be that I had not upgraded ruby 1.9.1 and
was
still using p243 or that I was running an old version of RubyParser. I
didn’t capture the version number that I was using. However I will go
find
that bit of information out and include it in more formal write up.

I think Adrian got the explanation right, however I am not sure since I
was
more focused mitigating the exploit rather than trying to refine it:

“I think that it is because RubyParser can only parse ruby 1.8 code.
Putting
the shell code in a 1.9-style proc confuses RubyParser. TryRuby will
think
that it is a syntax error and eval it without $SAFE set. Since the CGI
headers are already printed when the code is called, the call to p
will
print directly to stdout.”

The final problem was that I decided to change servers while all this
was
going on.
This violated the change one thing at a time rule. This was compounded
with
the sexp vs sexp_processor gem issue.

I realize that this email lacks the rigor needed to verify the claims
made
above.
When I have a few moments, I will gather the logs and write this up as a
blog post.

I would like to thank the RVM project for their awesome work.
Without RVM, Try Ruby would be a much more difficult project to host.
I am working on making Try Ruby a more manageable project.
This redeployment has been a great teacher in showing me where I am
doing it
wrong.

Respectfully,
Andrew McElroy

On Mon, Jul 12, 2010 at 6:53 PM, andrew mcelroy [email protected]
wrote:

Try Ruby is not compatible with 1.9.2-*. I am still looking in to why this
is the case, but ruby 1.9.2 will not execute tryruby.rb.
I am hoping that I am wrong about this, but every time I try to use 1.9.2 it
is unable to find tryruby.rb – even through it is in the same directly as
irb.cgi.

Now idea about your general setup, but that comment rings the bell
that “.” is no longer in $: by default.

On Mon, Jul 12, 2010 at 12:23 PM, Xavier N. [email protected] wrote:

irb.cgi.

Now idea about your general setup, but that comment rings the bell
that “.” is no longer in $: by default.

http://github.com/Sophrinix/TryRuby

I’m sorry if I sound like an idiot, but can you expand on what you mean
that
. is no longer in $

Do you mean that current directory is no longer in path?

Was this a change from 1.9.1 to 1.9.2?

Andrew McElroy

Yep, that was a 1.9.1 to 1.9.2 change:
http://www.ruby-lang.org/en/news/2010/07/11/ruby-1-9-2-rc2-is-released/

  • $: no longer includes the current directory

You’ve got to use relative_require, if memory serves.

On Mon, Jul 12, 2010 at 1:17 PM, Xavier N. [email protected] wrote:

path. If your app assumed it was chdir’ed to the CGI directory and did
a bare require it won’t work.

Was this a change from 1.9.1 to 1.9.2?

Yes.

Why was this change made? Will this behavior be backported to Ruby 1.8?
I guess reading the change log is pretty important then.

Andrew McElroy

On Mon, Jul 12, 2010 at 7:43 PM, andrew mcelroy [email protected]
wrote:

I’m sorry if I sound like an idiot, but can you expand on what you mean that
. is no longer in $

Do you mean that current directory is no longer in path?

That’s right, the current working directory is no longer in the load
path. If your app assumed it was chdir’ed to the CGI directory and did
a bare require it won’t work.

Was this a change from 1.9.1 to 1.9.2?

Yes.

On Mon, Jul 12, 2010 at 8:36 PM, andrew mcelroy [email protected]
wrote:

Why was this change made? Will this behavior be backported to Ruby 1.8?
I guess reading the change log is pretty important then.

It happened in changeset 23816, no rationale there. And I’ve seen only
speculation online (it is the tradition, UNIX security, etc.). I don’t
know the real motivation.

Having fun working through the tutorial - It’s like _why’s back from the
dead!

However when you: require ‘popup’ it gives the ‘you aren’t allowed to
run that command’

thought you’d like to know

The reason I saw cited was that it was causing problems when loading
libraries that were named the same as your program file, for example:

require 'twitter'

in a file called ‘twitter.rb’, which would be a script you intended to
interact with Twitter.

On Mon, Jul 12, 2010 at 3:55 PM, jonty [email protected] wrote:

Having fun working through the tutorial - It’s like _why’s back from the
dead!

However when you: require ‘popup’ it gives the ‘you aren’t allowed to run
that command’

thought you’d like to know

Yeah, It is a pending security issue. We didn’t want someone
orchestrating a
ddos from try ruby.

Andrew McElroy

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs