Ruby on Fails: Zombie SERVER army built thanks to Rails bug A critical vulnerability in trendy web programming kit Ruby on Rails is being abused to conscript hacked website servers into a growing botnet army. A security bug (CVE-2013-0156) in the open-source application framework was patched in January, but months later many website owners have failed to apply the update, leaving code …
If you're using RoR, you already haven't thought enough about separation of development and production platforms as it is.
"apt-get install build-essentials" (other package management systems are available) is just too tempting when you're trying to hotfix a production problem. It's absolutely the wrong thing to do for so many reasons, but again, if you're using RoR, you already haven't thought enough about...
In this particular case seeing as the attacker can transfer files and trigger execution of a program it looks to me as hiding the dev tools would be pretty pointless - as they could simply transfer & execute binaries instead of going to all the trouble of compiling their hacks on the victim's box. ;)
There should not be any harm in having dev tools on your server, as long as the appropriate privileges chosen and are enforced correctly... Personally I wouldn't be too worried about a compiler lurking around, all it does is read a bunch of files and generate a file out the back end, it's no different from most other apps out there. I think that time and energy would be better spent ensuring that the privs are set correctly in the first place.
The tramp in the picture is waiting for a cut of Visual Studio where *none* of it's tools require Admin privs. He has been waiting for many years and will probably die before that happy day arrives.
"What about firewalling outgoing connections?"
Exactly.
Webswervers are disposable. Ours has been compromised on a number of occasions - but because it's in its own subnet that's firewalled in BOTH directions, it's never been able to sucessfully participate in any attacks.
From the CVE it's clear that the vulnerability is due to RoR trying to do parameter quoting itself rather than enforcing prepared statement and relying on the database driver to quote. This is common in convenience frameworks.
So, it's the difference between the following Python-style pseudo-code.
connection.execute("SELECT * FROM table WHERE x = ?", (paras)) <- as safe as the DB can make it
and
connection.execute("SELECT * FROM table WHERE x = …") <- only as good as you can make it.
Unless audited - and even then it's only as safe as your confidence in the audit.
Unauthorised remote users is the least of the security worries. You stil have to worry about maliciously clueless local users and they're stilll the majority of a security admin's problems.
(Some of the stuff they attempt to do with personally identifiable data would make any DPA admin's hair turn prematurely grey.)
That's not really fair to Ruby (the programming language) though, this is a failure of Rails (the application framework). You can write insecure applications in Java, too.
Though the point is that Java doesn't need an extra application framework. Java itself has its own framework, which does most of the low and mid-level stuff out of the box. Rails, Maven and other craptastic frameworks were built for platforms where there is no base framework within the language/platform: Ruby, PHP, you name it.
Though the point is that Java doesn't need an extra application framework.
Ah. I must have imagined J2EE engines, then.
Java itself has its own framework, which does most of the low and mid-level stuff out of the box.
As does Ruby. For that matter, if you use JRuby, you have the whole Java framework.
Rails, Maven and other craptastic frameworks were built for platforms where there is no base framework within the language/platform: Ruby, PHP, you name it.
Nonsense. Rails does exist because the base Ruby language doesn't include a modular MVC web server framework, but then neither does J2SE. Maven is a build system - I have no idea why you're lumping it in here. PHP has a "framework", if you can call it that, of random functions loosely adapted from other languages or based on whatever idea someone at Zend had at three o'clock in the morning. All of these languages have a zillion add-on packages written by third-party contributors, of wildly varying quality.
There's no qualitative difference among the languages themselves in this regard.
Now, Rails does have many shortcomings - but that's not due to some failing in Ruby. Putting the whole MVC web serving architecture into the base language would be stupid and a complete failure to separate concerns properly.
And Ruby doesn't "need" Rails to be used as a server-side web application engine either. Rails is popular, but it's by no means mandatory for the task.
Also, isn't targeting web servers a little risky for botnet admins. Think about it, they are far more likely to actually be administered by someone who knows what theya re doing and monitors incoming/outgoing traffic, whereas home connections - well most people don't know or care what is going in/out as long as they get their facebook.
I don't think it matters much. Don't put too much faith in server admins knowing security that well.
Webservers are simply easier to find and, therefore, attack than home computers. Once compromised they probably have access to lots more bandwidth. On the other hand good ISPs will probably have monitoring in the data centre which should notice traffic spikes or the installation of certain types of exploits and may proactively shutdown compromised resources.
"Webservers are simply easier to find and, therefore, attack than home computers."
TBH I wouldn't be surprised if the zombie controllers specifically targetted mega-hosting outfits like rackspace, given a concentration of clueless users in these kinds of environs, often under multiple layers of reseller.
It's hard to track spikes in this kind of environment unless you want hundreds of false alarms per hour.
Think about it... the vulnerable servers are the ones which haven't been patched in 4+ months, therefore the sysadmins are not on the ball. Natural selection at work.
Home users, with their limited bandwidth, are more likely to notice when facebook is slower than normal because their (448Kbps upstream) connection is saturated; whereas on a server you could have a constant 10Mbps go relatively unnoticed.
.... the sysadmins. A lot of the time you will find that the management will not provide extra money for another host to move the site to while you can safely patch the first, and will not allow you to take the one host offline to patch no matter how much you state the importance of fixing security holes. Remember most managers bonuses are based on KPI's and as long as the server is hitting that uptime requirement they won't let you do a damn thing to it.
A couple of years ago, a certain forum for a certain IT-related website had part of its userbase posting links to vulnerable websites. Some of them were immediately defaced by jokers, and while a couple of them were quickly fixed, at least one of those remained in its damaged state.
For months.
If instead of joke defacements, someone had dropped a botnet there, it would have done their job for quite some time...
The vast majority of Rails installations wouldn't need to be updated if Rails were properly designed for security, with features disabled by default to minimize the attack surface. There's no need for XML parameter parsing to be enabled by default; there's no need for YAML and Symbol parsing to be enabled within XML parameter parsing by default.
Out of the box, only the minimum required feature set should be enabled. Simple as that. And Rails has gone through at least one update that broke pretty much all existing sites; that was the development team's opportunity to fix this. They didn't.
This is one of those basic security principles that continues to elude most developers, and probably always will.
...this article is slamming Rails for being vulnerable, even though the issue itself was patched (rightly) months ago.
I'd prefer a much more open attitude to the article acknowledging that there are many other web frameworks/languages with KNOWN vulnerabilities, which have gone unpatched for far longer than 6 months. For example - how many insecure PHP servers are there out there which have already been subsumed into a botnet? Attacking Rails, and Ruby by extension, for this is plain wrong.
Servers don't have eyes, or any other sense come to that. They anesthesically obey every instruction they get presented with.
Nor do they have any innate intelligence, so they cannot be tricked.
Perhaps the root cause of this "poor design hitting one in the face again" issue is people's idiotic tendency to anthropomorphize machinery.
Tron has a lot to answer for.
"Perhaps the root cause of this "poor design hitting one in the face again" issue is people's idiotic tendency to anthropomorphize machinery."
In case you're not aware smarter people than you or I have been anthropomorphising computers for many years. If you want to go ahead and call people like Bill Gosper and Richard Greenblatt idiotic though go right ahead...
"In case you're not aware smarter people than you or I "
Speak for yourself Cameron.
I am a self-confessed genius, bon vivant and boudoir athlete without equal (grunt grunt), and though I sometimes drink beer it is rarely Dos Equis because I find the people who drink it too boring.
I would have been swayed by your argument had your highly reasoned example not contained a sophomoric logical flaw that not only pulled its teeth but reversed its sense as a Dimwit Indicator. You can find it explained in Wikipedia if you are half as clever as you think you are.
Get with the times, granddad. RoR is old news... the cool kids all moved on to using node.js aaaaages ago.
I'm of the opinion this is a good thing; it is a sign of product maturity. I don't care much for RoR, but Ruby (and especially JRuby) are pretty useful tools these days.
"Why dontcha load in that program via the plugboard over there?"
It's called a Patch Panel sonny.
Now get off my lawn before I fire this here blunderbuss and pepper your c-loving arse cheeks with a hail of doorknobs, gravel and sundry nuts and bolts.
"The problem is the cool kids today have no idea how memory management works."
A real computer system takes care of memory management behind the scenes. Even the old ICL 1901T could manage that without falling over its germanium transistors.
Did you kids throw out the baby with the bathwater *again*?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
