
What The Rails Security Issue Means For Your Startup - timcraft
http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/
======
pifflesnort
The "everybody has bugs" response is intellectually dishonest. Yes, everybody
has bugs, but most people's bugs aren't an intentional feature that a trained
monkey ought to have known was a bad idea.

\- Someone implemented a YAML parser that executed code. This should have been
obviously wrong to them, but it wasn't.

\- Thousands of ostensible developers used this parser, saw the fact that it
could deserialize more than just data, and never said "Oh dear, that's a
_massive_ red flag".

\- The bug in the YAML parser _was reported_ and the author of the YAML
library genuinely couldn't figure out why this mattered or how it could be
bad.

\- The issue was reported to RubyGems multiple times and they _did nothing_.

This isn't the same thing as a complex and accidental bug that even careful
engineers have difficulty avoiding, after they've already taken steps to
reduce the failure surface of their code through privilege separation, high-
level languages/libraries, etc.

 _This is systemic engineering incompetence that apparently pervades an entire
language community, and this is the tipping point where other people start
looking for these issues._

~~~
patio11
Any sufficiently advanced serialization standard will let you
serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are
passing large amounts of XML back and forth over the wire, it is often going
to get instantiated via calling a zero-argument constructor and then firing a
bunch of setter methods. As J2EE has learned to its sorrow, there are some
good choices for objects to allow people to deserialize and some not so good
ones.

<http://wouter.coekaerts.be/2011/spring-vulnerabilities>

If J2EE is a boring platform to you, pick your favorite and Google for a few
variants. You'll find a serialization vulnerability. It's hard stuff, by
nature.

* The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.*

Do you have a citation for this? What particular bug _in the parser_ are you
referring to? The behavior which is being exploited is a fairly complicated
interaction between the parser and client Rails code -- I banged my head
against the wall trying to get code execution with Ruby 1.8.7's parser for
over 12 hours, for example, without any luck unless I coded a too-stupid-to-
be-real victim class. (It's my understanding that at least one security
researcher has a way to make that happen, but that knowledge was hard won.)

~~~
pifflesnort
> _Any sufficiently advanced serialization standard ... it is often going to
> get instantiated via calling a zero-argument constructor and then firing a
> bunch of setter methods._

Yes, this is always a bad idea. It's actually in a similar problem space as
the constant stream of vulnerabilities in the Java security sandbox (eg,
applets); all it takes is one mistake and you lose.

And thus, people have been saying to turn off Java in the browser for 4+
years, and this is also why Spring shouldn't have implemented such code.

> _It's hard stuff, by nature._

Which is why deserializing into executable code is a bad idea, by nature. I'd
thought this was well established by now, but apparently it is not.

> _Do you have a citation for this? What particular bug in the parser are you
> referring to?_

<http://github.com/tenderlove/psych/issues/119>

~~~
jrochkind1
> Which is why deserializing into executable code is a bad idea, by nature.
> I'd thought this was well established by now, but apparently it is not

I'm not sure that means anything. In an OO language, you are always de-
serializing into objects, and objects are always 'executable code'. Hashes and
Arrays are executable code too, right?

The problem is actually when you allow de-serializing into _arbitrary_ objects
of arbitrary classes, and some of those objects have dangerous side effects
_just by being instantiated_, and/or have functionality that can turn into
arbitrary code execution vector. (Hopefully Hash's and Array's don't).

It is a problem, and it's probably fair to say that you should never have a
de-serialization format that takes untrusted input and de-serializes to
anyting but a small whitelisted set of classes/types. And that many have
violated this, and not just in ruby.

But if you can't even describe the problem/guidance clearly yourself, I think
that rather belies your insistence that it's an obvious thing known by the
standard competent programmer.

(I am not ashamed to admit it was not obvious to me before these exploits. I
think it was not obvious to a bunch of people who are in retrospect _claiming_
it was obvious to.).

~~~
revelation
What you are looking for is not "OO language", but "dynamic interpreted
language".

In a traditionally compiled OO language like C++, classes cease to exist after
compilation; there is no fully generic way to instantiate an object of a class
by data determined at runtime. So this whole concept of deserializing to
whatever the protocol specifies goes completely out of the door.

~~~
phil
"Interpreted" is too restrictive. For example, Objective C provides
NSClassFromString().

~~~
revelation
One could argue that since every call goes through a runtime messaging
framework, Objective C is really just an interpreted language with pre-JITed
function bodies.

------
mikegirouard
This quote caught my attention:

    
    
        There are many developers who are not presently active on a Ruby on Rails
        project who nonetheless have a vulnerable Rails application running on
        localhost:3000.  If they do, eventually, their local machine will be
        compromised. (Any page on the Internet which serves Javascript can, currently,
        root your Macbook if it is running an out-of-date Rails on it. No, it
        does not matter that the Internet can’t connect to your
        localhost:3000, because your browser can, and your browser will follow
        the attacker’s instructions to do so. It will probably be possible to
        eventually do this with an IMG tag, which means any webpage that can
        contain a user-supplied cat photo could ALSO contain a user-supplied
        remote code execution.)
    

That reminded me of an _incredible_ presentation WhiteHat did back in 2007 on
cracking intranets. Slides[1] are still around, though I couldn't readily find
the video.

[1]:
[https://www.whitehatsec.com/assets/presentations/blackhatusa...](https://www.whitehatsec.com/assets/presentations/blackhatusa07/0807blackhat_hacking.pdf)

~~~
purephase
Other than ease of setup, I've never understood why you wouldn't develop in
the same environment as what you're running in production. Setting up a vm is
trivial and allows you to easily open/close access to your application as
needed.

There is also a lot less headaches once you've decided to move it into
production.

~~~
brown9-2
I don't think this would be any more secure if you were to enable networking
on the VM to allow requests from the host machine, which seems like common
behavior so that the developer can access the webapp running on the VM from a
browser on the host. Or are people developing inside a VM and then testing
with a browser on the VM?

~~~
digisth
You can set up a cloud VM (on Rackspace for example), and then set up your
VM's firewall (iptables) to only allowing connections from your test machines
(could be your local IP, or the IP address of the test machines from
Browserstack or Sauce.) This allows you to keep your dev/staging/prod
environments in sync (and allows you to do things like blueprint/image your
dev setup to build it elsewhere), decouple your dev from your staging/prod,
and allow you to develop from anywhere without needing to carry around the
same laptop or rebuild your dev environment on another box - particularly if
you use an intermediate system with a static IP so you can reconfigure your
firewall whenever needed.

------
jammycakes
When I look at the Ruby/Rails community, the word that comes to my mind more
than any other is _hubris_.

You see this in things such as security issues being marked as wontfix until
they are actively exploited (e.g. the Homakov/GitHub incident), in the
attitude that developer cycles are more expensive than CPU cycles, and on a
more puerile level in the tendency towards swearing in presentations.

I've always had the impression that the Rails ecosystem favours convenience
over security, in an Agile Manifesto kind of way (yes, we value the stuff on
the right, but we value the stuff on the left even more). One of the
attractions of Rails is that it is very easy to get stuff up and running with
it, but some of the security exploits that I've seen cropping up recently with
it make me pretty worried about it. I get especially concerned when I see SQL
injection vulnerabilities in a framework based on an O/R mapper, for instance.

~~~
trekkin
I have the same impression.

Many start-ups are built by well-meaning people who have no formal CS or even
engineering background and thus are somewhat out of touch with what it means
to build a robust system. It's natural for people to focus on "what's
important" and ignore boundary/edge conditions, while in reality 90% of sound
engineering is getting boundary/edge cases right.

And as most of such start-ups use Ruby/Rails due to the easiness of "getting
it up and running", and thus they inject the Ruby/Rails ecosystem with this
"focus on what's important" mindset, important boundary issues, including
security, are neglected.

------
firemanx
I think the recent Rails, Java, RubyGems and other vulnerability issues have
been an absolute boon to the industry. And not just for the increased business
I think most security consultants are going to be seeing.

The exploits have happened in ways that have exposed and hammered home the
myriad places many applications expose unexpected side channels and larger
attack surfaces than you'd think. These issues have opened a broader range of
people to vulnerability, and I think opened a lot of people's eyes to the need
for a sense of security and what that really means.

Top that with the level of explanation we've seen in at least the Rails and
Ruby exploits, it's been a tremendous educational opportunity for a lot of
people who will benefit greatly from it, and by proxy their users.

When the idea of a "SQL Injection" first became really prevalent, we saw an
uptick in concern for security amongst framework developers, as far as I could
tell. I think this will help get some momentum going again.

Speaking as a non-expert on the subject, security is all about a healthy sense
of paranoia, across the board :)

~~~
martinced
+1

I was going to post something similar. Also we often see people insulting
others when they post exploits too early or describe exploits in depth too
early. Posting stuff like: _"You're an .ssh.le, wait a few days before posting
that"_.

I don't think so. I think exploits should be publicly posted as soon as
possible and affecting as many people as people. Maybe even damaging exploits,
actively deleting users data or servers data.

The bigger the havoc, the sooner the entire industry is going to realize
security is a very real concern.

People are still considering buffer overflow, SQL injection, query parameters
objects instantiation through deserialization exploits, etc. to be "normal"
because "everybody creates bugs" and "a lot of bugs can be exploited".

I think it's the wrong mindset. Security if of uttermost importance and should
be thought of from the start.

For example I'm amazed by the recent seL4 microkernel which makes buffer
overflow provably impossible (inside the microkernel) or even the Java VM (the
JVM) which makes buffer overflow in Java code impossible. It's not perfect
(we've seen _lots_ of major Java exploits, but zero were buffer
overrun/overflow in Java code... Some in 3rd party C libs, but zero in Java
code. Some other Java exploits too of course, but zero buffer
overrun/overflow).

So security exploits are _not_ a fatality.

All we need is people, from the very start, to conceive systems more
resilients to attacks.

The more attacks, the more exploits, the more bad reputation and shame on
clueless developers, the better.

I actually start to love these exploits, because they fuel healthy research by
the white-hat community.

And one day we'll have more secure microkernels, more secure OSes, more secure
VMs, more secure protocols, etc.

Let them security exploits come.

------
jcampbell1
It would be interesting if someone wrote a worm that just took all the
vulnerable rails apps offline. That way we would have less worry about a
million compromised databases. It could be launched from a bookmarklet run
from tor browser, and would probably exhaust every ip address in a few days.
It would also land whoever did it in jail for a really long time.

~~~
InclinedPlane
Maybe, though with today's legal climate such a thing would be extremely,
extremely risky. Gaining unauthorized access to a computer system and
exploiting it in a way that potentially causes loss of revenue is not
something you want to do lightly even if it might be the right thing to do.

------
tomjen3
This is a pretty good example of why I hate big frameworks. They are simply
too big to prevent stupid issues like YAML extraction in JSON and XML.

If you are like me, you would expect that YAML was used in the configuration
files and _nowhere_ else. A small framework like Sinatra wouldn't have been
big enough to hide an issue like this.

~~~
SilasX
Really? Has a giant framework like Django had bugs this severe, that allowed
data-file parsers to execute arbitrary attacker code?

~~~
gingerlime
Nearly. Both piston and tastypie (the two leading frameworks for writing APIs
for django) were affected by a very similar code execution vulnerability a
while ago. see [https://www.djangoproject.com/weblog/2011/nov/01/piston-
and-...](https://www.djangoproject.com/weblog/2011/nov/01/piston-and-tastypie-
security-releases/)

~~~
mpyne
Those were both third-party modules for Django (albeit popular ones). But at
best, this means that Rails devs have known since Nov 2011 or so that YAML
code should be carefully audited, _especially_ since there was _no_ equivalent
in Ruby for Python's .safe_load
([http://stackoverflow.com/questions/14348538/is-there-an-
equi...](http://stackoverflow.com/questions/14348538/is-there-an-equivalent-
to-yaml-safe-load-in-ruby)).

I don't mean to beat on the Rails guys too hard though, they're off shipping
stuff and I'm not and I'm not very fond of those who criticize while a safe
distance from the action. But I think it's fair to say that this could have
been foreseen earlier (or much earlier, depending on who you ask).

------
ontoillogical
> The recent bugs were, contrary to some reporting, not particularly trivial
> to spot. They’re being found at breakneck pace right now precisely because
> they required substantial new security technology to actually exploit, and
> that new technology has unlocked an exciting new frontier in vulnerability
> research.

What technology is he talking about here?

~~~
patio11
Basically, a new way to combine things we already know about. Like, you might
have already unlocked "stone axe", "vines", and "dry wood", but given those
three primitives I can show you a novel way of combining them that repeatable
produces fire. We know have a fun and exciting new way to use commonly-
accepted-general-purpose-programming-tools to blow stuff up, and are iterating
-- rapidly -- on bringing other previously-assumed-safe constructs into the
"blows stuff up" zone of knowledge.

~~~
ontoillogical
I'm not sure I get what you're the analogy to.

When I first read your blog post I got the impression that you were saying
that the YAML vulnerability were found with some new code scanning technology
that lets us find bugs in Rails faster. Or are you just saying discovering the
existence of the YAML.load() class of vulnerability is "new security
technology?"

Or are you talking about the ronin support module people are using in some of
the PoCs?

~~~
patio11
So if I had told you at Christmas three salient facts:

\+ Some objects are unsafe to instantiate if you don't pick all values you
initialize them with very carefully.

\+ YAML can instantiate objects from any class.

\+ Rails uses YAML, in a lot of ways.

You might have said "Yes, I am aware of all these three things. Do you have
anything important to tell me?" Now, if I demonstrate to you working PoC code
which combines those three into remote code execution, the _substantial_ work
involved in producing that PoC code -- finding the vulnerable classes which
ship with Rails, demonstrating how to get data from where the user controls it
into the far-inside-the-framework bits where Rails might actually evaluate
YAML, etc etc -- immediately starts suggesting lots of other fun ways to use
variants of that trick.

~~~
lucian1900
Anyone competent would, when knowing those three things, immediately think of
the possible exploits.

~~~
diminoten
And yet they didn't, and here we are.

Yes, it's _super_ easy to call everyone involved with the YAML library
incompetent, but let's be honest - they're not, in general. They fucked up
here, and hindsight is 20/20, but I think it's only face-stabbingly obvious
now because of what's actually happened.

~~~
mpyne
I wouldn't necessarily blame the YAML _library_ devs, assuming they documented
that it could instantiate arbitrary classes.

I do more Perl but I can tell you that "this deserializer can create new
arbitrary objects" would give _screaming_ alarm bells. And that is because
there is a long history of trying (and failing) to safely do stuff like this
(e.g. note the lack of warrant for the Safe CPAN module:
<http://search.cpan.org/~jhi/perl-5.8.0/ext/Opcode/Safe.pm> )

Python has the same well-known and well-documented issue with their pickle
module.

In general using /any/ deserializer that can create arbitrary objects of
arbitrary classes has been known to be a bad idea for some time, and as far as
I can tell Ruby YAML documents that it supports doing exactly this:
<http://www.yaml.org/YAML_for_ruby.html#objects>

So if we were talking about a security vuln from something like JSON where we
expect benign data to be the only possible output I think I'd agree
completely.

Using a deserializer even more powerful than that is at the very least a bad
smell from the POV of security, especially post-Spring (fixed in 2011, even if
it was re-iterated 2013), so I wouldn't be so quick to claim this could only
have been predicted in hindsight.

I get that it's still hard work to move from "I made an object of my choosing"
to "framework pwned" but you pretty much _have_ to assume that the former
implies the latter nowadays. It was more than 5 years ago now that tptacek was
gushing over Dowd's "Inhuman Flash Exploit" and I somehow don't think that pen
testers and security experts have gotten any dumber since then. ;)

------
bguthrie
This was a hugely helpful big-picture overview of the recent vulnerabilities.
Everyone, please go read it.

I had been meaning to get some context for the recent spate of security
problems and this provided that in spades. Thanks for taking the time to write
it up and post it.

------
true_religion
> The first reported compromise of a production system was in an industry
> which hit the trifecta of amateurs-at-the-helm, seedy-industry-by-nature,
> and under-constant-attack. It is imperative that you understand that all
> Rails applications will eventually be targeted by this and similar attacks,
> and any vulnerable applications will be owned, regardless of absence of
> these risk factors.

Who was the first reported compromise of a production system?

~~~
jplewicke
I believe Patrick is referring to this Bitcoin exchange being hacked:
<http://news.ycombinator.com/item?id=5043122> .

------
josephlord
All the RubyGems stuff is happening at a high rate and I understand that over
90% of the Gems are now verified and it looks like nothing was backdoored but
I couldn't find a good summary of the current situation so I have a couple of
questions.

1) Is it currently safe to "bundle update" and be confident that only verified
Gems will be provided? I don't mind errors on any unverified ones but don't
want to download them.

2) Is there a drop in replacement for RubyGems? The problems that have
occurred this month would have been multiplied if RubyGems was unavailable at
the time Rails had an apocalyptic bug.

~~~
purephase
Pretty good breakdown going on here [1]. To be honest, while the chosen tool
to provide the update is odd, it is one of the best post-mordems that I've
seen and applaud the volunteers for taking it so seriously.

1\. I wouldn't say so. Not until they're all the way through.

2\. Not at the moment, but general guidance is that we should all have local
gem repos that we maintain ourselves and only rely on external sources when
needed. It is something I'm going to look into ASAP.

[1]
[https://docs.google.com/document/d/10tuM51VKRcSHJtUZotraMlrM...](https://docs.google.com/document/d/10tuM51VKRcSHJtUZotraMlrMHWK1uXs8qQ6Hmguyf1g/edit?pli=1#)

~~~
josephlord
It is extensive and up to date but it is lacking a brief status of the current
situation and whether the site is safe to download from. The answer is
currently "no", 90% safe is unsafe.

It's a shame that they seem to have put the service back up in an unsafe mode,
I would have hoped that they could have quarantined the unverified Gems.

Edit: Looking at the status page the API is down so it can't be accessed from
Bundler so they are doing it the good/safe way.

------
jmount
This blindness to how bad YAML was is causing "convention over configuration"
to devolve into "security by convention".

~~~
jacquesc
you mean "insecurity by convention"?

------
lucian1900
To me it seems that all of this is due to the obsession with implicit
behaviour in Rails, and to some extent Ruby.

I hope they learn from this and stop chanting "convention over configuration"
when told that explicit is better than implicit.

------
kyllo
Is this YAML vulnerability something that can be patched in relatively short
order without Rails itself having to be completely rewritten?

Or should I basically just not run Rails on any machine ever anymore, get a
different web server, and start implementing my own request routing and ORM
without any sort of YAML-parsing magic?

>One of my friends who is an actual security researcher has deleted all of his
accounts on Internet services which he knows to use Ruby on Rails. That’s not
an insane measure.

So anyone who uses Twitter, for example, could have their passwords and other
data stolen through this exploit?

~~~
patio11
_Is this YAML vulnerability something that can be patched in relatively short
order without Rails itself having to be completely rewritten?_

Long story short: There's a variety of things that can be done to mitigate
this vulnerability and an active conversation on which is the best option. My
go-to suggestion would be having Rails ship with either a non-stdlib YAML
serialization/deserialization parser or have it modify the stdlib one, with
the major point of departure being "Raise an exception immediately if the YAML
encodes any object not on a configurable whitelist, and default that whitelist
to ~5 core classes generally considered to be safe."

 _Or should I basically just not run Rails on any machine ever anymore, get a
different web server, and start implementing my own request routing and ORM
without any sort of YAML-parsing magic?_

That is astonishingly unlikely to be a net-win for your security.

 _So anyone who uses Twitter, for example, could have their passwords and
other data stolen through this exploit?_

I'd expect that Twitter (in particular) has a better handle on it than your
average startup, but successful exploitation of this means the attacker owns
the server, if the attacker owns the server they probably get all the servers,
and they will tend to gain control of any information on all of the servers.
That can include, but is certainly not upper-bounded by, passwords/hashes
stored in the database. It is _absolutely_ possible, and indeed likely, that
many people will be adversely affected by this vulnerability without
themselves running Rails or even, for that matter, knowing what Rails is.

~~~
kyllo
>>Or should I basically just not run Rails on any machine ever anymore, get a
different web server, and start implementing my own request routing and ORM
without any sort of YAML-parsing magic?

>That is astonishingly unlikely to be a net-win for your security.

In the long run, you are probably right. Once this gets fixed, which will
probably be soon considering how much attention is on it.

But in the short run, is there anything worse than a vulnerability that allows
a remote attacker to automatically detect, penetrate, and execute arbitrary
code on your machine? To the point where it's not even safe to run the
framework on localhost on your dev box?

------
ph0rque
So I went through my heroku closet and cleaned everything up (pulling the plug
on unneeded apps and making sure needed apps were up to date).

My question: do these security issues affect Sinatra apps?

~~~
cheald
These issues affect all apps which deserialize arbitrary user-specified YAML.
I suspect Sinatra doesn't provide any attack surface by default here, but
Sinatra apps tend to have a lot of bolted-on functionality, so it's worth
doing an audit of any Sinatra apps you run to make sure you haven't introduced
any exploitable surfaces.

------
delinka
"Any page on the Internet which serves Javascript can, currently, root your
Macbook if it is running an out-of-date Rails on it."

Why are you running Rails as the root user? This is a bad idea.

EDIT: I'm not really into client-side JavaScript these days, but when did
browsers start allowing JavaScript to connect to anything except the server
from which it came? That would be yet another Bad Idea.

~~~
btilly
You have bad assumptions. It is all about leveraging access to higher and
higher levels.

1\. You load the evil JavaScript.

2\. That JavaScript adds an image with a URL pointing at localhost:3000.

3\. When you load that URL, it causes code execution, causing your computer to
open a connection somewhere and start taking instructions.

4\. The instructions that arrive includes downloading and installing software
that takes advantage of known local root vulnerabilities in OS X.

5\. Congratulations! Someone rooted your machine!

Nothing in this path required Rails to be run as root, or JavaScript to
directly connect anywhere.

~~~
delinka
You're right. I wasn't seeing all the angles here. But to say this is limited
to Macs seems disingenuous.

~~~
btilly
He didn't say it was limited to Macs. He gave it as a random example of what
could happen.

~~~
delinka
I'm pretty sure OP specifically said "Macbook" in the article. But see
patio11's comment beside yours.

------
btown
Is Rails moving to a YAML (or almost-YAML) parser that does _not_ execute code
for future major releases? I find it hard to believe that such functionality
is used often. Until then, as the article says, people will just keep finding
zero-days. This seems like the only logical choice for the Rails core team.

------
sergiotapia
I'm losing my Ruby and Rails faith here; what gives? This is just as bad as
leaving SQL injection attacks open.

~~~
ynniv
_This is just as bad as leaving SQL injection attacks open._

No, it is much worse.

------
scarmig
Given the severity, it'd almost be a public service to hit every public Rails
server and exploit it to patch it with the security fix(es)...

------
drawkbox
New internet law: any sufficiently sized platform or framework will attract
increasingly more compromising/malware attacks. Anyone running Wordpress still
knows this all day.

------
romaniv
Some time ago I asked certain Ruby people how to dynamically load Ruby code
(for configs). They told me it's Wrong. Seems that in practice the idea wasn't
much worse than Yaml after all.

I am still convinced that configs and templates should be treated as
executable code and are best implemented in the same language they're used
from. At least it makes certain things blatantly obvious. (It also makes a lot
of other things possible without any extra coding/learning.)

------
rlpb
You do all deploy from your own cache of all the gems you depend on, right?
No? Why not?

~~~
purephase
I'd love to. Any helpful guides on how to proceed?

~~~
steveklabnik
I just wrote a blog post: [http://words.steveklabnik.com/how-to-not-rely-on-
rubygemsorg...](http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg-
for-deployment)

~~~
squidsoup
Wasn't aware of bundle --deployment, that's very helpful thank you steve.

~~~
steveklabnik
Any time! Not enough people are.

------
s1kx
Is there no hardened version of Psych which lets you either disable object
deserialization, or whitelist classes? That would seem like the safest option
right now to guard against coming vulnerabilities in Rails in this regard.

~~~
trapexit
This is currently being discussed on
<https://github.com/tenderlove/psych/issues/119>

There is also <https://github.com/dtao/safe_yaml> (hat tip @patio11, who also
points out that this has not been audited for completeness/correctness)

------
sneak
Why do people write things like "We Should Avoid #’#(ing Their #()#% Up"
instead of "We Should Avoid Fucking Their Shit Up"?

<http://www.youtube.com/watch?v=dF1NUposXVQ>

------
homakov
[http://homakov.blogspot.com/2013/01/rails-is-fragile-
vulnera...](http://homakov.blogspot.com/2013/01/rails-is-fragile-
vulnerabilities-will.html) This.

------
friendly_chap
It seems like the Ruby guys should spend a little more time learning the
basics of CS in between two self promotion ("rockstar developers", anyone?).

------
djkz
How feasible would it to have a gem that sits in middleware that would check
for possible attacks before the string gets any further and block/share IPs of
people fishing for exploits?

I could see it as a service company that shares blacklist info between sites
and can even find new exploits from the "bad" requests.

------
SkyMarshal
I'm not a Rails developer, is JRuby on Rails affected by this?

------
ams6110
Why don't we have "building codes" for software?

There was a time when anyone who claimed to have the ability could design and
build things like bridges and buildings. After enough of them collapsed due to
repeated, avoidable mistakes, we said no, you can't do that anymore, you need
to be licensed to design and build buildings, and furthermore you have to
follow some basic minimum conventions that are proven to work. And you and
your firm has to take on personal liability when you certify that your design
and construction follows those basic best practices.

------
hayksaakian
So what are the good versions of recent minor versions of rails? And where can
I find them in the future?

------
dschiptsov
Nothing. Neither recent Java flaws.

------
static_typed
As much as I was a fan of developing Ruby apps, I was constantly shocked by
the lack of engineering, security concern, stability of API, basically serious
software engineering within the community.

It would be good if all this was a clarion call to the Ruby community to
improve things holistically, rather than the current trend of band-aid fixes
they seem to apply.

~~~
hawleyal
ಠ_ಠ

Because other frameworks are rock-solid. Yup. None of this happens anywhere
else on the internet.

~~~
lucian1900
Nothing quite this catastrophic tends to happen to things that aren't PHP.

~~~
steveklabnik
That is simply not true. Here's an example linked upthread for Struts, for
example: [http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-
remote...](http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html)

------
martinced
Code execution while deserializating / parsing data is my first and uttermost
concern. Nowadays I'm in Clojure land and it's still not entirely clear as to
what I can and cannot do and what the language as to offer me so that data
doesn't contain rogue code that is going to be executed.

In Common Lisp, for example, as far as I know you can set a flag so that the
reader is set to "no evaluation ever" (if I understand things correctly) and,
hence, if you're not using eval yourself specifically, nothing is ever going
to be evaluated.

But how would that work in Clojure? And what about other languages? Ruby?
Haskell? Java? C#?

I think the ability to execute code became _the_ most important security issue
(more than buffer overflow/overrun which can now be prevented --even sometimes
provably impossible to happen thanks to theorem provers).

More thoughts should be put into explaining how/when a language / API can
execute code and how it should/can be used to prevent such a thing from
happening.

------
hawleyal
FUD much

~~~
patio11
Hiya, welcome to Hacker News. I'm Patrick and I wrote this article. I run four
businesses, three of which are intimately tied to Ruby on Rails, I am a
contributor in the community, and I want to see it win. If you believe I am
trying to spread fear, uncertainty, or doubt, you are greatly mistaken about
my motives.

As someone who loves Rails, to someone who presumably likes Rails, _it is
imperative that you understand_ how serious this issue is. If you use Rails,
you need to have addressed this already. If you have not, drop what you're
doing and go fix it _right now_.

~~~
redeemedfadi
Patrick, Thank you for writing this article. It opened my eyes to how serious
this issue is and how easy it is to compromise a server. Upgrading all my
rails apps now. Thanks again.

