
Use Rails? Check yourself for the YAML exploit - borski
https://www.tinfoilsecurity.com/railscheck
======
patio11
It might be worth mentioning "We determine this by sending a harmless request
to your web server. The request doesn't do anything -- it is designed to be
rejected with an error, much as if someone typed a URL incorrectly and
requested a web page which doesn't exist. If your application is vulnerable,
it will respond with a particular error code, whereas apps that are not
vulnerable will not. [bold]This vulnerability allows attackers to execute code
on your server, but we don't actually do this.[/bold]"

I mention this because I have lately had a lot of experience dealing with
Rails devs whose attitudes with regards to security are akin to "If you don't
do voodoo then voodoo can't hurt you." We should take special care when
communicating with them to a) emphasize that we're not the bad guys and b)
explain, as many times as required, that ignoring the bad guys does not make
the bad guys go away.

~~~
ainsleyb
Mind if we copy that verbatim? :)

~~~
patio11
Go for it.

------
patio11
You should mention that this will give false negatives for people who actually
are vulnerable but happen to be running Ruby 1.8.7, by the way. (I'm
distilling that from this part of the announcement blog post, plus the
knowledge that Syck is the default 1.8.X parser. It is indeed difficult to
exploit -- I banged my head into a wall for 12 hours attempting to do so --
but people who are highly credible to me on this issue report having
successful exploits for it.)

 _Also, this check is for websites using the Psych YAML Engine and not the
older Syck. All of the proof of concepts we've seen so far are for Psych. That
doesn't mean Syck isn't vulnerable, but that our checker will only work for
Psych. In all likelihood, Syck is vulnerable too and you should upgrade your
Rails all the same._

~~~
JangoSteve
The exploit gist was actually pretty easy to modify in order to correctly
identify if a Rails 2.3.x / Ruby 1.8.7 app was vulnerable. If you accept the
fact that "payload being interpreted as object deserialized from YAML" is bad,
then you don't necessarily need a malicious object to see if your app is
vulnerable. If you have access to your Rails logs, then you just need to see a
params value in your logs that's an object.

Here is my modified gist that can help you identify if your app is vulnerable,
which works with Rails 2.3.x / Ruby 1.8.7 apps. If you run this and see in
your Rails log something like "params = {#<ActionController... => {default =>
:action}...}", then your app is vulnerable:
[https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2...](https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2154a5816968e)

We also have a couple apps we know of that are really old Rails 2.2.x apps.
This doesn't work with them, because the passed YAML doesn't work in the old
YAML parser. But then, if you just trust that deserializing an object from
YAML in parameters is bad, then we can just make a super simple hash object
and check our rails logs to see if the params contain an actual hash object.
Here's an even-more-simplified-harmless proof-of-concept to test older Rails
2.2.x apps:
[https://gist.github.com/4694948/1e8a94f7c768bf95863288005039...](https://gist.github.com/4694948/1e8a94f7c768bf958632880050399904defba531)

I'm no security expert, but I was able to use these PoCs last night to verify
that the patch for Rails 2.3.x worked, and also that my reverse-engineered-
patch for Rails 2.2.x worked as well.

Edit: Just to clarify and reiterate, the above modified PoCs require access to
the Rails app logs to check if they worked or not, since the older Rails apps
could error out for YAML-parsing reasons (which are just as bad, because it
just means an attacker needs to get more creative with their YAML payload),
instead of being a result of rejecting the attack. That's why I don't think a
web-based attack mechanism like this could really know 100% whether or not an
app is vulnerable unless it really tried doing something semi-malicious, like
obtaining secret information.

~~~
borski
You're completely right. We call out that it isn't 100% certain if we return a
'not vulnerable'. Our full scan will soon include some code execution modules
for these vulnerabilities which will provide a more certain response.

------
orangethirty
After the fantastic post by patio11, I spent all afternoon emailing every
person in my network. Letting them know of the huge security risk. The answer
I got from most people? "We have backups, and plan to deal with it soon.
Thanks for the heads up." Really? This is the kind of stuff that made me
delete every simple rails project I had on my workstations, and just push them
to git. No sense in risking it.

Oh, and best of all was the response from my webhost (which is well known
here):

 _We've added updated Rails installers to our control panel so that new Rails
apps will be created with the latest secure versions. However, it's our
customers' own responsibility to upgrade their existing Rails apps.

Note that customer Rails apps run as unprivileged users, with resources
managed by the kernel cgroups feature, so its very unlikely that you'd see any
issues on your own sites if another customer's app was compromised._

Hmm, very unlikely but still possible. Not something I want to hear from the
people who Im trusting with my projects. I'm canceling my account tomorrow and
moving away from them. I know they are not responsible for their client stuff,
but this is a real threat to their servers.

~~~
rst
FWIW, some hosts were more proactive --- Heroku in particular sent out email
to the owners of vulnerable apps within a day or two of the announcement.

~~~
borski
EngineYard did this too, FWIW.

------
nestlequ1k
anyone have an open source command line tool to do this? call me paranoid (and
probably dumb) but I really dont want to enter this into another website

~~~
borski
I can tell you we're trustworthy, but I hear where you're coming from. :)

With that said, you can use Metasploit for this too - we just wanted to make a
really easy checker for those that wanted a quick OK/NO GO and didn't want to
deal with setting Metasploit up.

Metasploit docs here:
[https://community.rapid7.com/community/metasploit/blog/2013/...](https://community.rapid7.com/community/metasploit/blog/2013/01/10/exploiting-
ruby-on-rails-with-metasploit-cve-2013-0156)

~~~
nimblegorilla
You are providing a valuable service, but is Metasploit really necessary for
this? I think this is a simpler command:

'grep rails Gemfile.lock'

If you don't see a rails version of 3.2.1, 3.1.10, 3.0.19, or 2.3.15 then you
are vulnerable. Yes?

I guess in theory an attacker could have compromised your server and changed
the rails version number...

~~~
ef4

        3.2.1 is not safe (you probably meant 3.2.11)
        3.0.19 is not safe (3.0.20 was released to fix CVE-2013-0333)
        2.3.15 is not safe (2.3.16 was released to fix CVE-2013-0333)

~~~
nimblegorilla
Good point. I just copied the version numbers from the linked website - I
guess it was outdated. Although I checked again and they are correct now.

------
venus
Does this work, at all? I get nothing but "There was an error - please double
check the URL and try again". There is no-one in the support chat provided. As
far as I can tell it simply does not work.

And, to head off the inevitable comments, yes, it's free, I know: I'm just
letting people know not to waste their time with something of zero value.

~~~
borski
Sorry about that! Can you email support@tinfoilsecurity.com and I'll take a
look? It's 11PM here and we've taken a few hours to rest. :)

------
copremesis
I think this page is hoax ... just an attempt to gather a list of rails urls.
looking at my logs I see no such request.

~~~
Harkins
I think it can't deal with the traffic it's getting. I saw a couple of hits to
my server and the page's progress bar moved a little, but it's been stalled
for quite a while now.

~~~
borski
Are you referring to the scan from our homepage or the Rails checker? Either
way, could you get in touch with us at support@tinfoilsecurity.com or
<http://www.tinfoilsecurity.com/chat> ? I'd love to see what went wrong.

We shouldn't be having issues with load.

------
scotje
I just tried this on one of my side project sites and it's reporting it as
being vulnerable. However I upgraded the site to Rails 3.2.1 last week (and
just confirmed that's the version in the bundle). Is there something that
would cause a false positive or is my app really still vulnerable?

~~~
borski
There is the potential for false positives, but I'd be happy to chat about it
- feel free to get in touch either via email at support@tinfoilsecurity.com or
in our support chat: <http://www.tinfoilsecurity.com/chat>

ITYM 3.2.11? 3.2.1 is definitely vulnerable... We had a typo in ours that said
3.2.1 was safe - so sorry about that! Fixing that now. You should upgrade to
3.2.11.

~~~
scotje
Aha, well apparently I never merged that commit into my deploy branch, so it
was still actually on 3.2.1. That combined with the fact that your page had
said 3.2.1 was safe caused my brain to short circuit and not realize that
3.2.11 is what it needed to be on. :) I'll redeploy and check it again, thanks
guys!

~~~
borski
Yeah, that was totally our bad. I'm deploying the typo fix now.

Let me know if you have any other issues! Happy to help.

~~~
scotje
See, in a very circular way I was just reporting the typo. :)

(Looks good now that I have the right release deployed, by the way.)

~~~
borski
Ha, fair point. :)

Glad you got it fixed!

------
pacala
Out of technical curiosity, would it be reasonable to remove YAML from the
source tree and check for the lack of exploit via "find $APP_ROOT -name "*.rb"
| xargs grep YAML"?

~~~
patio11
You cannot conveniently remove YAML from Rails. It is used in dozens of places
in the framework, including some code paths which your app is virtually
guaranteed to exercise.

------
aneth4
This doesn't seem to work. It returns the OK for apps I know I have not
patched (simple stuff I've thrown up on heroku).

It's possible heroku is filtering the headers...

~~~
borski
We know it's not supposed to be 100% reliable, but we haven't seen any false
positives so far, actually; only false negatives.

Are you using Syck instead of Psych? If so, that would cause it to return the
OK instead, since our check only works for Psych.

------
tibbon
So what is the exploit, and how do we fix it?

~~~
patio11
There have been multiple vulnerabilities discovered with semi-related causes.
These all have (several) exploits which are widely available. The upshot is
that they permit remote code execution (i.e. "root the server") on virtually
all Rails applications accessible on the public Internet and, perhaps, some
which are not.

Rails has been updated to close these particular vulnerabilities. The proper
versions are listed in these two advisories. There are also work-arounds if
your app is not in a state to just upgrade Rails. If your app is in that
state, I _strongly advise you_ that your only priority for the next several
days is fixing that, because _one should have high confidence that there will
be more vulnerabilities announced soonish_.

[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/1h2DR63ViGo)

[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/61bkgvnSGTQ)

------
phillc
Single location to aggregate a list of all vulnerable apps.

~~~
borski
See my response here: <http://news.ycombinator.com/item?id=5153615>

You are more than welcome to use Metasploit - a lot of our customers didn't
want to go through the trouble of setting up their own Metasploit config,
etc., so we built this to give them a simple quick check.

------
static_typed
Rails Security is apparently "omakase" - meaning 'leave it to someone else',
apparently.

~~~
wasd
Do you pose any interesting facts or thought to these discussions? I've seen
you post in nearly every single one of these threads with nothing
constructive. I understand that "you used to use Rails" and are much happier
now that you're leaving the "insecure framework" but do you need to post it in
every single thread?

Disclaimer: I'm a java programmer.

