A
andrew mcelroy
[Note: parts of this message were removed to make it a legal post.]
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:
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
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:
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