
Multiple vulnerabilities in parameter parsing in Action Pack - jfirebaugh
https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion
======
benmmurphy
An attacker can execute any ruby code he wants including system("unix
command"). This effects any rails version for the last 6 years. I've written
POCs for Rails 3.x and Rails 2.x on Ruby 1.9.3, Ruby 1.9.2 and Ruby 1.8.7 and
there is no reason to believe this wouldn't work on any Ruby/Rails combination
since when the bug has been introduced. The exploit does not depend on code
the user has written and will work with a new rails application without any
controllers.

Here is the commit where it was introduced:
[https://github.com/rails/rails/commit/27ba5edef1c4264a8d1c0e...](https://github.com/rails/rails/commit/27ba5edef1c4264a8d1c0e54675723d37a391dd8#L5R133)

~~~
jerf
I don't speak Ruby. Can you or someone else be more precise about where that
introduces the vulnerability? (Surely it isn't that YAML::load(content) can
run arbitrary shell code?)

~~~
tptacek
Calling YAML::load on attacker-controlled content in a Ruby app of any
complexity is very bad news. As Ben and 'judofyr said: this is remote code
execution.

~~~
aaronblohowiak
Is this because Yaml doesn't whitelist the classes for the objects that may be
instantiated? They are allocated and then instance_variable_set'd so I'd be
_Very_ interested to learn how this poses a risk.

~~~
tptacek
The people saying that they have POC code for remote code exec aren't making
it up.

~~~
aaronblohowiak
If I implied that I doubted them, then I failed to communicate my point
effectively -- I am very curious about how to turn a class allocate +
instance_variable_set into remote code exec. I see how you can create the arel
objects for sqli, but not arbitrary ruby.

~~~
jgeralnik
If you wait a couple of weeks you are much more likely to get an answer. Since
all rails apps were vulnerable, most people who know how to execute arbitrary
code are keeping silent for now.

------
tenderlove
I'm just commenting here so that people can have a central thread for love /
hatred. ;-)

But seriously. This is extremely critical, please upgrade!

~~~
ghayes
As there have been many exploits / issues recently realized in parameters
parsing, why isn't there more of a focus on security here? Specifically, this
is where users/hackers can put _ANY DARN THING THEY WANT_ and your server has
to deal with it.

As a simple solution, one could pass a signed auth-hash of the fields
generated by form_for, and the server could re-hash the fields submitted to
ensure the form data you asked for is what you get (this solves the primary
issue with attr_accessible). I feel getting this right is crucial to Rails'
future.

~~~
steveklabnik
> why isn't there more of a focus on security here?

More compared to what, exactly? This vulnerability was responded to pretty
damn quickly after it was reported, given that almost nobody is even paid to
work on Rails. If you saw Aaron tweeting about "working over the weekend" a
few days ago, well, now you know.

That said, you mention attr_accessible in your post: that's gone as of the
next release of Rails. Basically everyone agrees that strong_parameters is a
better approach, which is why a gem was released that works with 3.2: you can
use that better approach now.

As was mentioned below, security is a process, not a result. Nobody wants
these kinds of issues to happen, but they will happen, and do to every single
framework that's used by lots of people.

~~~
smackfu
Nothing gives me confidence in a platform like "almost nobody is even paid to
work on Rails."

~~~
lgleason
I thought some come of the core committers had their work sponsored by their
employers.

~~~
steveklabnik
Aaron is the only person on core who is paid to work on Rails. (Among other
things.)

I am a committer, and part of my job is to work on open source. Ish.

Other than that, it's everyone else's spare time, IIRC.

~~~
lgleason
Wow, that actually gives me more confidence because we have people doing it
because they feel passionate about it. Thanks for your hard work....

I've been busy with some other small OS projects (and stuff that pays the
bills) but personally feel like I need to try to carve out some time this year
to do something to contribute back to Rails.....

~~~
steveklabnik
<3

If I can help you help us somehow, please let me know.

------
benmmurphy
This vulnerability is also present in other other Ruby libraries. I would
advise anyone to do bundle install --deployment in there development
environment then 'grep -r "YAML::load"' and 'grep -r "YAML.load"' in the
vendor/bundle directory. If you have YAML::load(user_controlled_value) or
YAML.load(user_controlled_value) then you might be vulnerable to remote code
execution. There are some other ruby libraries that are vulnerable to this
attack but I don't want to post about them until their authors have fixed
them.

~~~
zwily
Good reminder, but this has always been true. Giving unfiltered user-specified
content to YAML has never been a good idea.

------
teyc
I don't use Rails, and read up on the vulnerabilities. Here's a quick summary:

1\. This class of problems is not unique to Ruby.

2\. Similar problems have been identified in Struts, and python's pickle.

3\. Specifically in this case, YAML.load() can deserialize unintended object
types. In the case of Struts the problem was the expression library used can
also deserialize unintended object types (like File), plus setting properties
on these types can have side effects (such as dropping files into your
system).

4\. I took a look at Microsoft's WCF. The DataContractSerializer states that
it only is allowed to load types that are specified by a contract.
[http://msdn.microsoft.com/en-
us/library/vstudio/ms733135(v=v...](http://msdn.microsoft.com/en-
us/library/vstudio/ms733135\(v=vs.90\).aspx) This should be the gold standard.
In addition, it warns that even loading XML documents can be dangerous if we
then load remote DTDs for validation.

5\. For the old salts, remoting or RMI have similar issues - both mitigated by
restricting the types that can be deserialized. [http://msdn.microsoft.com/en-
us/library/5dxse167(v=vs.71).as...](http://msdn.microsoft.com/en-
us/library/5dxse167\(v=vs.71\).aspx)

6\. Here's another vulnerability which targets serialization
<http://wouter.coekaerts.be/2011/spring-vulnerabilities>

In summary,

1\. all deserializers should be viewed with suspicion.

2\. A deserializer which does not implement a whitelist of types that it can
deserialize to is not suited for handling arbitrary data.

3\. For example, it is capable to creating untainted/trusted objects in
application servers, which some time later, may be used for XSS, or execution
in SQL. In the Struts case, the standard Java libraries have constructors and
methods that deserializing is enough to result in an arbitrary file being
dropped on the remote file system.

~~~
tptacek
Very similar vulnerabilities have definitely been discovered in other
platforms.

This vulnerability is most similar to the object loader vulnerabilities found
in Spring a few years back. It is the kind of vulnerability that is
occasionally found in Java web stacks.

It is a simpler vulnerability. This is a double edged sword. On the one hand,
it is easier to fix (and to be sure we've fixed) than the objectloader-type
stuff. On the other hand, it's so easy to reason about and work with that the
exploit is straightforward. It was very difficult to find ways to talk about
the general pattern of weakness in this code without immediately disclosing
the exploit.

The vulnerability is similar in spirit to Python's Pickle, which is also
unsafe for untrusted data. A difference between Raila and Django, though:
while specific Django apps have had Pickle exposures, I'm not sure Django
itself ever did.

PHP has vulnerabilities that are similar in impact to this vulnerability. But
there's a big difference between this flaw (and the Python issues) and PHP:
PHP grappled for years and years with a publicly known bug class (remote file
inclusion) that coughed up code execution. It's not impossible that more RCE
flaws will be found in Rails, but it's unlikely to become a class of bug that
every Rails developer will need to adopt best practices to stop.

No mainstream web platform has ever survived long deployment in popular
applications without some horrible finding. Nobody's hands are clean. It is
very difficult to get security right in every single component that a full-
featured web framework needs to offer. It only takes one mistake.

You are dead right about deserializers in general.

------
judofyr
This is bad, bad, bad, bad! SQL injections, remote code execution, DoS. Pretty
much _everything_ is possible with this exploit. You don't even need the
secret key which was required in the previous vulnerability.

Upgrade _NOW_.

------
xentronium
<http://www.insinuator.net/2013/01/rails-yaml/>

Some explanation why YAML user input is evil.

It works like this

    
    
        1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML
        "1 --"
    

It looks like string, but it's not.

    
    
        1.9.3p327 :002 > Keyword.where(:id => id).first
          Keyword Load (0.3ms)  SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LIMIT 1

~~~
charliesome
Posting the gory details this early on is not a nice thing to do. It's
probably best to hold off for a while until everyone has had a reasonable
chance to upgrade.

~~~
merlincorey
Do you think not selling guns on an open market stops criminals from obtaining
them as well?

~~~
tptacek
If anybody thinks we're solving vulnerability full disclosure once and for all
on an HN thread about a Rails vulnerability, that person is pretty naive.

We've now officially captured both sides of the argument and can safely move
on.

------
danso
Before anyone wonders if they're having deja vu, this is different than the
SQL injection vulnerability that was discussed 5 days ago:

<http://news.ycombinator.com/item?id=4999406>

~~~
tptacek
This isn't a SQL injection vulnerability at all.

~~~
joevandyk
But you can use this to trigger the earlier SQL injection vulnerabilities,
right?

~~~
ajross
It's (apparently) a remote code execution bug. You can also use it to trigger
SQL in the sense of _simply executing arbitrary SQL_. There's no need to
bootstrap or trampoline, the doors are swinging open already.

------
steveklabnik
To emphasize:

    
    
        > Due to the critical nature of this vulnerability, and the fact that portions
        > of it have been disclosed publicly, all users running an affected release
        > should either upgrade or use one of the work arounds *immediately*.

------
FooBarWidget
I'm the author of the "Rails SQL injection vulnerability: here are the facts"
blog post last week. This vulnerability is a different and unrelated one, and
is very serious. Upgrade immediately.

------
fwilhelm
For those of you interested in more details about this bug: I've posted a
first analysis at <http://www.insinuator.net/2013/01/rails-yaml/>

~~~
steveklabnik
I don't think this is very responsible of you. You should post this, but you
should really wait a week or so.

~~~
marshray
According to tptacek, "it was discovered by multiple teams independently" and
"Lots of people have working proof-of-concept exploits for this".

I think your week started Jan 02 with CVE-2012-5664.

~~~
steveklabnik
But it was not knowledge to the general public until today. That's what
matters. Those people have POCs, but they're not spreading them.

~~~
marshray
One should never assume that he has a handle on everyone who knows the
existence of a bug.

I think you underestimate your adversary.
<https://twitter.com/mikko/status/288766998228393984>

~~~
steveklabnik
You completely mis-understand my point. I don't think that this is the only
person who knows this, that'd be idiotic. They are, however, the only person
who posted it in this thread. Giving it more publicity. I don't think that
that extra publicity is appropriate.

~~~
marshray
Even now you _still_ think it's useful to hide information from the "general
public" and avoid "extra publicity"?!

The cat is out of the bag. You can no longer negotiate with this reality.

Publicly disclosing a bug is like birthing a baby. Once it's sticking halfway
out, just get it all the way out because it's counterproductive to try to hold
parts of it back in.

~~~
tptacek
Gross, dude.

~~~
marshray
Yeah, that analogy definitely seemed more elegant before I wrote it out.

------
rschmitty
Rails noob here... with this and the other vulnerability from a few days ago,
do all you need to do is update your rails gem to become safe?

Current version at time of my post is 3.2.11, if I'm using that am I safe or
do I need to perform additional steps?

~~~
cschneid
That is correct. The latest 3.1.10, or latest 3.2 series have this update. See
the top of the linked notice:

Versions Affected: ALL versions Not affected: NONE Fixed Versions: 3.2.11,
3.1.10, 3.0.19, 2.3.15

------
Argorak
This hits one my basic complaints about Rails: it activates too many features
_by default_. Even if your app does not parse XML params, the parser is
active. I know its convenient, but hey - is this worth the price of exposing
_everyone_?

~~~
tptacek
That's not a fair critique here. The problem isn't that Rails exposes XML by
default. Everyone knew it did, and just processing XML isn't the issue.

The problem is that the XML code used in the untrusted request path was also
used by code that handled trusted messages elsewhere, and those trusted
messages had requirements that weren't appropriate for request-path messages.

Because JSON is so much more popular than XML in Rails apps now, a reasonable
workaround for this problem is to just turn off XML if you're not using it.
More importantly, it's a workaround that (a) does more to reduce the attack
surface given how XmlMini works, and (b) was a workaround that disclosed less
of the vulnerability last week. But don't let that confuse you about the
nature of this bug.

~~~
Argorak
Yes, it is a valid critique. You are right that just deactivating XML parsing
is a reasonable workaround - and in my opinion so reasonable that it should
never be activated by default in the first place.

A lot of people get bitten by a component they never consciously used and
activated in the first place. While the second part is true for almost every
part of a framework, the first one is problematic. ("XML? Why do I have a
vulnerability through XML and YAML in a JSON-only app?")

------
moe
I hope in consequence of this incident the Rails-team will build in an
automatic security-update notification mechanism.

I'd like my apps to poll rails.org (or whatever) every few minutes and by
default shutdown hard when an incident like this is announced.

~~~
davidw
You can set up a system like Debian or Ubuntu to automatically install
security updates.

~~~
moe
I want my rails instances to shutdown within minutes of an announcement, not
hours or days.

~~~
xnxn
Headline of the future:

> Tens of Thousands of Rails Applications Remotely Disabled Following
> Rails.org Intrusion

~~~
moe
Yes, that is to be expected - and absolutely worth it.

The aftermath of an incident like the current one is a lot more expensive than
an unplanned downtime.

~~~
xnxn
Just playing devil's advocate here: a truly evil attacker could use the access
logs from all the apps phoning home to build a list of vulnerable targets! :)

~~~
moe
Well, you are right, the idea wasn't thought out very well. I was in a bit of
a bad mood during patching up various rails deployments around here...

However, perhaps they could just promise to post a signed message, in a
specified format, on a dedicated twitter account, if such a thing happens
again. This would seem like a relatively low-tech approach, about adequate for
such a rare event (just keep that secret key secret!).

The community can then roll their own gems to watch said twitter-account and
act according to any user preference. Perhaps one of these gems would even
make it into rails-core after sufficient review.

Obviously one can always argue whether such a rare case deserves dedicated
infrastructure. But on the other hand we have yet to see how many rails
deployments will be bitten by this incident in the long term. It's not
uncommon to see years of exploitation for a vulnerability in a popular piece
of server software.

~~~
bradleyland
Your entire thread of comments here make me want to gouge my eyes out. A
signed message on twitter? Low tech? What in the hell are you talking about?

I'm going to be the asshole here, because it is vitally important that no one
responsible for security ever listen to what you're saying. You're advocating
some Orwellian kill-switch mechanism based on unspecified "signed messages"
over a third-party social messaging service (limited to 140 chars, no less),
and throwing in meaningless phrases like "low tech". What about this problem
leads you to believe we all need something low tech?

I am not qualified to design such a system. You are negatively qualified to
even comment on such a system. Please stop.

~~~
moe
I'll try to put this more politely:

Since you apparently neither understand what was discussed (an _optional_
rather than an "Orwellian" kill-switch), nor the implementation options (a
signed message via any broadcast mechanism), nor why using twitter as the
transport would be feasible and "low-tech" versus most alternatives, you
should perhaps refrain from commenting on this thread at all. - And especially
not in that tone.

------
sergiotapia
As a newcomer to the Rails ecosystem all these posts of vunlerabilities and
open doors leaves a bad taste in my mouth.

God know I love programming in Ruby now, but is Rails really that insecure?

~~~
jrabone
Who'd have thought it? Hugely dynamic language turns out to be difficult to
audit or analyse for security issues.

It was never about Java(C, C++) vs. Ruby despite what fanboys on either side
made out. It was about conservative vs. devil-may-care. All that "convenience"
and "it's so clean" came at the price of a whole load of code executed behind
the scenes. You didn't write it, and the Gods of TDD preached that you don't
need to test it because that's Someone Else's Problem. Auditing it is nearly
impossible not least because it's a moving target, so you either get stuck in
a backwater of obsolete versions that once got audited and approved or you
live on the bleeding edge constantly (and DevOps hate you forever).

FWIW we (large satnav company) prototyped the last major service in Rails
(actually a one-man hack proof of concept) then implemented it in production
in Scala (and that was a bridge too far for a lot of people) because no-one
wanted to run Rails in production.

~~~
phillmv
This is a straw man.

These kinds of issues are open to all software.

I'm happy you work in the kind of place that audits all of its software,
though. I'm sure you've all read through all of Hibernate, Spring and not to
mention all the .NET framework code.

~~~
papsosouid
>These kinds of issues are open to all software

Really? Could you show me how I could possibly create such a hole in a
language like ocaml or haskell?

~~~
chimeracoder
> Could you show me how I could possibly create such a hole in a language like
> ocaml or haskell?

First you'd have to _write_ the equivalent of Rails in Haskell (I'm not
talking about an MVC framework, but something as large, complex, and
featureful.)

~~~
papsosouid
No, I am asking how you could actually create this vulnerability in haskell at
all. No framework required, just actively, intentionally trying to create this
hole.

------
tptacek
Patch right now.

~~~
vinhboy
Someone should change the title of this post. I didn't read it for a good 3
hours because I didn't realize it was related to Rails.

~~~
cdcarter
I hate to say it, but if you're running a public facing Rails application,
it's near imperative that you know what Action Pack is and why it's
significant.

------
jrochkind1
Hmm, this may explain why the vulnerability patched in 3.2.10 was more
dangerous than it seemed, eh?

The 3.2.10 announcement provided an example of `Model.find_by_id(params[:id])`
as an exploit, but nobody could figure out how you could get a hash with a
_symbol_ key into `params[:id]`, which is what it would take for that to be an
exploit. So people were confused.

But the pre-3.2.11 exploit, apparently, possibly provides ways to do just
that, eh?

~~~
jgeralnik
That's how this vulnerability came to light. After finding out about the last
vulnerability, there was a huge amount of interest in seeing if parameters
could be exploited, leading to a number of people simultaneously discovering
this flaw.

------
derwiki
I heard through the grapevine that YC affiliated companies were tipped off to
this exploit/patch before it was made public (really; a YC affiliate asked me
today about the vuln before it was disclosed). Could anyone comment on that?

~~~
tptacek
The existence of this vulnerability (without details) was disclosed publicly
last week. So far as I know, nobody was told any details about the
vulnerability itself; just that a patch was coming, and it was very important
to apply it.

------
jacobn
So I've applied the workaround, which is great, but how do I test that the
workaround is indeed working?

I realize that providing an in-depth answer is tantamount to publishing an
exploit how-to, but some reasonable way to privately test this would be very
useful.

Maybe a "simple" URL tester hosted by a trusted Rails source (e.g.
rubyonrails.org)? Ok, has the obvious issue of showing the world who they
should target, but maybe you can riff on that theme?

Auditing and stuff you know. For some reason people in charge get really upset
when all our base are belong to the bad guys.

~~~
espes
[https://github.com/rails/rails/commit/46e0d2397ea10a0bf38092...](https://github.com/rails/rails/commit/46e0d2397ea10a0bf380926c9fe3cfcf14d5c499#L0R119)

------
batgaijin
At least people are getting practice at following security bulletins.

------
Kafka
I might be the last one on earth that still runs a Rails 1.1.x app. This time
the ancient one dodged a bullet.

"ah, actually 1.1.x isn't vulnerable. The issue first arrived in 2.0" -
<https://twitter.com/tenderlove/status/288777229276704768>

~~~
benmmurphy
we had some rails 1.x apps at work and we were happy.

------
willvarfar
Why doesn't Ruby (and Python and all other languages) have Perl's tainting
built in and always running?

I'm not advocating it as the only security mechanism, but rather as another
barrier to be overcome just like address-space-randomisation, data-exection
prevention and all the rest...

(Haven't Google recently shared a valgrind-lite runtime bounds checker which
is being incorporated into GCC etc? Might lead the way on how this can be down
with the minimum of runtime cost.)

~~~
headius
Because tainting is an inherently flawed way to do security. Blacklisting
capabilities/methods/data _always_ leaves holes behind, and it's nearly
impossible to secure a system using tainting alone. Even the Perl folks say it
shouldn't be used as a security mechanism...it should be used to help thin out
security issues during development and testing.

If you want to secure a system...whitelist, don't blacklist.

~~~
teyc
If the runtime overhead is low, then shouldn't tainting be used _in addition_
to other techniques? ala Defense in depth?

~~~
headius
You certainly can do that. You can also add more and more locks to your doors
while leaving your windows open.

------
sdoowpilihp
Can anyone with a more intimate knowledge of the inner workings of Ruby on
Rails speak to how detrimental this exploit is in practice? I seem to recall a
fair number of people feeling the SQL injection exploit from a few days ago
was being blown out of proportion and I was wondering how this particular
exploit stacks up against it.

~~~
danso
I'm not going to say "told you so" because I said nothing and I'm just a
layman in this...but when people were pointing out last week that the bug was
"overblown" I had wondered if they were underestimating the tendency for such
vulnerable patterns to propagate. The mechanisms that let even an edge case in
are not always isolated.

~~~
martinced
Oh I'm saying "told you so". Since years and years.

The real problem is the very mentality of the people who downplay security
issues, always saying _"this is not a serious issue"_ (or, worse, saying _"but
language xxx / framework yyy"_ suffers from issues too, it's how the world
works).

That mentality is the reason why such exploits do exist in the first place.
Security is nearly always an afterthought.

The most braindead argument being: _"My goal is to sell xxx, not to have an
unbreakable server"_.

Once you read that one, you know you have reached the low of the low.

~~~
FooBarWidget
Or maybe some issues are overblown, while others are not.

Also, the message was not "overblown". It was "don't panic, but still upgrade
ASAP".

------
caseyf
I was curious about why Rails parses YAML nested inside XML to begin with.
Turns out it was put in way back when so that ActiveRecord's from_xml/to_xml
work as expected when a model contains serialized (ie. yaml) attributes.

Patch/issue from the old Rails issue tracker:

[http://web.archive.org/web/20071218105822/http://dev.rubyonr...](http://web.archive.org/web/20071218105822/http://dev.rubyonrails.org/ticket/7502)

------
10char
Correct me if I'm wrong, but looks like this should only be a vulnerability if
your app uses XML parameters?

~~~
tptacek
No, it's a vulnerability if your app SUPPORTS XML parameters, which _all
modern Rails apps do_.

This vulnerability is exploitable even if you don't have any exposed
controllers.

~~~
vinhboy
Wait, what? What if the app does not parse ANY user provided XML or YAML at
all?

~~~
tptacek
That does not matter.

~~~
vinhboy
Holy cow. I just figured out how to send the payload. This thing is seriously
bad news.

I still haven't figured out an attack vector yet, but least I now know that my
patches are working!

------
jasonlingx
Thinking aloud, do we need some kind of auto-update feature for rails apps?
This kind of exploit suddenly exposes the multitude of Rails apps out there to
remote code execution. I know it wouldn't be a trivial thing to make, but we
already have yum auto update for linux and auto updates for Windows, OS X etc,
it should definitely be feasible. Scope could be severely limited, so for
example, a monkey patch for big vulnerabilities like this, while sending a
notification email to the app maker.

~~~
charliesome
Replacing one RCE with another :)

------
amix
I am shocked that it's considered a smart idea to make it possible to execute
code from XML files (and that this is the default setting)!?

~~~
jgeralnik
Of course it's not considered a smart idea. That's why this was fixed. It was
a (critical) bug.

------
viseztrance
I really don't understand the last part "This vulnerability was reported to us
by numerous people, many thanks to [...]".

Considering it affects all versions, what are the odds of multiple people
pointing this out at the same time?

Rails has a very good track record regarding these things, but I'm just
curious.

~~~
tptacek
The last Rails SQLI vulnerability was mitigated by the way ActionPack parsed
request parameters, so lots of people dove into that code to see if the
mitigation could be evaded with JSON or XML. That gave people incentive to
review Rails XML parser wrapper class. The problem with that class is pretty
obvious.

~~~
viseztrance
Makes perfect sense. Thanks for pointing this out.

------
benmmurphy
if you are using extlib gem you may be vulnerable as well.

it has just been updated:

[https://github.com/datamapper/extlib/commit/633974b2759d9b92...](https://github.com/datamapper/extlib/commit/633974b2759d9b924657f3888473d5fd681538dd)

------
andrewnez
I've thrown together a little script for checking your github repos for out of
date rails apps: <https://gist.github.com/4492021>

Should come in handy today.

------
callmevlad
Github.com (built on Rails) is currently having issues. If I had a tin foil
hat, I'd put it on. Hopefully their issues are not related to this
vulnerability.

~~~
senorprogrammer
More likely the result of millions of Rails site owners crying out in
terror... pulling and then committing updates. I fear something terrible has
happened.

------
costad
As someone stuck maintaining an older rails app with no hope of upgrading
anytime soon, any information on patching rails 2.1.0 against this
vulnerability?

~~~
wigsgiw
Best idea would be to apply the workarounds presented for Rails 2.3 in the
group post: [https://groups.google.com/forum/#!topic/rubyonrails-
security...](https://groups.google.com/forum/#!topic/rubyonrails-
security/61bkgvnSGTQ/discussion).

Place a couple of lines in a file in config/initializers, and you're good,.

------
thewillcole
Heroku apps rely on Heroku's version of Rails gems (right?), so how does one
tell if Heroku has patched these vulnerabilities yet?

~~~
willlll
Heroku runs whatever version you say in your Gemfile. You must update your
apps yourself; There is nothing Heroku can do to update your app for you.

~~~
thewillcole
But am I protected if I'm currently using a fixed version of Rails? (3.2.11,
3.1.10, 3.0.19, or 2.3.15)

~~~
willlll
yes

------
amalag
For a less hammered server, can use:

source '<http://bundler-api.herokuapp.com>

in your Gemfile

~~~
1qaz2wsx3edc
Gems are unsigned. Patching from a different source is idiotic. Do not use:
you have no clue who is the owner.

~~~
amalag
Not so idiotic if you know the owner. It is done by Heroku's Ruby team

[http://hone.heroku.com/bundler%20heroku/2012/10/22/rubygems-...](http://hone.heroku.com/bundler%20heroku/2012/10/22/rubygems-
and-the-dependency-api.html)

------
chunkyslink
Ok. I'm quite new to Rails. How do I apply this patch? Or am I better
upgrading rails completely? How do I do this.

~~~
elektronaut
Update to 3.2.11, 3.1.10, 3.0.19 or 2.3.15, and you'll be good.

~~~
chunkyslink
Already in my gem file ...

gem 'rails', '3.2.3'

I think that patch maybe? But I dont know how. Google is not helping,

~~~
elektronaut
Change it to

    
    
      gem 'rails', '3.2.11' 
    

and run

    
    
      bundle update rails

------
martinced
I'm tired of the logical fallacy that consists in always saying: _"Every
software suffers from security issues"_.

It is just plain wrong to reason like this.

So let me ask something to the ones using the above fallacy: are all programs
(say webservers) equals in the face of security?

It's an easy question right? And the answer is: "no, they're not all equal".

So stop saying: _"But Java had several DoS bugs affecting Tomcat in 2011 too,
so we're not doing anything wrong here"_.

And start coding (and documenting) to higher standards.

~~~
berkes
You make it sound as if "Every software suffers from security issues" was
brought up as a reason not to put effort into security. It was not.

It is very valid to reason within constraints of reality. Like knowing that a
car "which will never ever have an accident. ever" is a lie. We know that
driving a car brings a risk of an accident. That is realism. Some turn that
reality into dangerous behaviour. Saying things like "Statistics tell me I
will have an accident no matter what. So I can just as well finish this bottle
of whiskey before driving at 150Km/h home". You are making it sound as if the
Rails developers follow that logic.

They don't. There simply is a certain realism that, no matter how much effort
you put into security, there will be security issues. But nothing more. Or
less.

------
the1
ruby on cracks

------
fernandezpablo
1\. Keep this link bookmarked.

2\. Pull it off next time someone starts with the 'test-replace-static-typing'
argument.

3\. WIN

~~~
prodigal_erik
This problem is due to deserialization creating object (sub)graphs which are
unintentionally too powerful. Statically typed languages (especially without
dependent types) can do this too, even when the root object(s) matches the
type(s) expected by the caller. The cure is
<http://en.wikipedia.org/wiki/Capability-based_security>: write out what the
caller is currently allowed to do, rather than blindly granting dangerous
privileges and relying on the code's design never to use them. Even tainting,
a very crude manual form, seems like it could have caught this.

------
clickonchris
Upgrade instructions:

update your Gemfile and set the version you want. In my case:

gem 'rails', '3.2.10'

locally, run

'bundle update rails' which will update your Gemfile.lock

check-in and deploy your code. If you are using capistranso, the default
'deploy' task should handle everything for you. Otherwise, run 'bundle update
rails' on your production server.

~~~
jrochkind1
3.2.11 not 3.2.10.

Which is in fact why it's probably wiser to list `gem 'rails', '~> 3.2.10'`
(or 3.2.0 or anything) instead, and then `bundle update rials` will update you
to latest 3.2.x (but never 3.3.x), in this case 3.2.11, instead of only to the
exact version you specified (3.2.10, incorrectly).

