back to article 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 on …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

force a vulnerable server to download, compile and run some C code

Hindsight is 20/20, but should you have dev tools installed on such a server? What about firewalling outgoing connections?

3
0
Silver badge

Re: force a vulnerable server to download, compile and run some C 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...

10
0
Roo
Silver badge
Windows

Re: force a vulnerable server to download, compile and run some C code

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.

8
0
Silver badge

Re: force a vulnerable server to download, compile and run some C code

"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.

3
0
Anonymous Coward

@Alan Brown

"Webswervers...."

Very well put indeed.

0
0
FAIL

Bloody hell! People give Java stick, but at least it's only really dodgy when run in browsers, server side Java is fairly secure. This looks like a whole other kettle of fish.

2
0
Silver badge

Progamming style

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.

2
1
Silver badge

all code is unsafe

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.)

3
0

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.

5
0
Silver badge
Boffin

Ruby/Rails vs. Java

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.

0
0
Paris Hilton

Re: Ruby/Rails vs. Java

"Java doesn't need an extra application framework. "

What are JSPs then? And why do so many recruiters seem to want me to have this skill?

0
0
Silver badge

Re: Ruby/Rails vs. Java

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.

1
0
Anonymous Coward

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.

0
0
Silver badge

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.

3
0
Anonymous Coward

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.

6
0
Bronze badge

You shouldn't always blame ....

.... 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.

3
0
Silver badge

"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.

2
0
Silver badge
Boffin

Webservers and lazy sysadmins

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...

0
0

Being fair to Rails

This was patched months ago. If sysadmins haven't applied the patch then there's nothing the Rails devs can do.

5
0
Silver badge

Re: Being fair to Rails

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.

1
0

So, basically....

...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.

3
0
Stop

Re: So, basically....

To be fair, the article did also mention a recent exploit in WordPress.

0
0
Silver badge

Re: So, basically....

The sins of other frameworks do not excuse those of Rails. The attack surface on Rails, in a stock installation, is much too large. That's a systemic failure to design for security.

1
0

Not sql injection

The vulnerability was unrelated to SQL injection. The problem was a vulnerability in the YAML & XML parsers combined with the fact that rails will automatically deserialize data posted in those formats

2
0
Silver badge

Bah!

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.

0
2
Silver badge
Joke

Re: Bah!

Not Tron's fault for anthropomorphism, how about the iPad:

http://www.theregister.co.uk/2012/01/26/ipad_fleshlight_design/

1
0
Coat

Re: Bah!

So have apple patented Tron now?

0
0

Re: Bah!

"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...

0
0
Silver badge

Re: Bah!

"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.

0
0
Anonymous Coward

"trendy web programming kit Ruby on Rails"

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.

0
0
Anonymous Coward

Re: "trendy web programming kit Ruby on Rails"

The problem is the cool kids today have no idea how memory management works. But then again this is not a new problem the cool kids using VB had the same problem in the 90s.

3
0
Silver badge
Trollface

Re: "trendy web programming kit Ruby on Rails"

Hey Gramps, still worrying about memory management?

Why dontcha load in that program via the plugboard over there?

0
0
Silver badge

Re: "trendy web programming kit Ruby on Rails"

"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.

2
0
Gold badge
Unhappy

AC @ 17:45

"The problem is the cool kids today have no idea how memory management works. But then again this is not a new problem the cool kids using VB had the same problem in the 90s."

They'll learn of course.

Eventually

0
0
Silver badge

Bah!

"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*?

0
0
This topic is closed for new posts.

Forums