Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Multiple Security Holes In Ruby 1.8, 1.9

kdawson posted more than 6 years ago | from the that-ain't-good dept.

Security 148

ruphus13 notes a six-pack of serious vulnerabilities discovered in Ruby by a member of Apple's security team, Drew Yao. Patches are linked from the ruby-lang.org advisory. "With the following vulnerabilities, an attacker can lead to denial of service condition or execute arbitrary code... These vulnerabilities are likely to crop up in just about any average ruby web application. And by 'crop up' I mean 'crop up exploitable from trivial user-specified parameters.' It's not hard to begin imagining cases where Ruby/Rails programmers use code similar to the samples above to routinely handle user input."

cancel ×

148 comments

Sorry! There are no comments related to the filter you selected.

omg (-1, Offtopic)

Elisanre (1108341) | more than 6 years ago | (#23901775)

oh nose, it can't be the first *hide*

Derailed (2, Funny)

lemur3 (997863) | more than 6 years ago | (#23901787)

I can see the blood now!

Re:Derailed (0)

Anonymous Coward | more than 6 years ago | (#23902481)

Apple on security. Oxymoron ? Maybe they should stick to their own software holes (Carpet bombing anyone?) before they comment on others.

Re:Derailed (2, Informative)

Lars T. (470328) | more than 6 years ago | (#23902719)

"Carpet bombing" neither executed arbitrary code nor has it not been fixed.

Re:Derailed (0)

Anonymous Coward | more than 6 years ago | (#23903785)

Was there not a recent demonstration on a 'blended threat' based on the safari bug that would execute code next time IE ran, also I beleive there is another similar method for firefox 2/3.

Re:Derailed (1)

Poltras (680608) | more than 6 years ago | (#23905059)

What part of "bug solved in 3.1.2" did you not understand? It's not like it's the first security hole that took a month or two to solve.

Re:Derailed (2, Insightful)

Lars T. (470328) | more than 6 years ago | (#23906135)

Was there not a recent demonstration on a 'blended threat' based on the safari bug that would execute code next time IE ran, also I beleive there is another similar method for firefox 2/3.

No, there still is a bug in IE that will run any properly named DLL on the Desktop, whether it is downloaded with the "Carpet Bomb", or by hand with any browser, download tool (incl. FTP or P2P), or moved there, or put there by fairies. And there is also a bug in Firefox that allows somebody to "steal files", which has probably to do with a certain kind of file being in its Download Folder (by default the Desktop) - again, no matter how it got there. These are bugs that need to be fixed.

Re:Derailed (0)

Anonymous Coward | more than 6 years ago | (#23903929)

This is about as stupid as saying, "Gosh, the Republicans are trying to stop gay marriage. I'm sure glad that terrorism, murder, rape, theft, and piracy have all been fixed!"

It's quite reasonable to be looking at multiple problems at a time, and furthermore, it's quite possible that Drew didn't have anything to do with Safari development.

But then, look at me. I'm replying to a troll.

The real story (-1, Flamebait)

dreamchaser (49529) | more than 6 years ago | (#23901831)

The real story here is how quickly the bugs were patched. I'd like to see MS respond half as fast to holes in Windows and it's attendant parts and pieces.

Re:The real story (1, Informative)

Anonymous Coward | more than 6 years ago | (#23901857)

The bugs found are fairly basic honestly.

If these were found in any MS product it wouldnt matter how fast they were patched.

Re:The real story (3, Insightful)

JeremyGNJ (1102465) | more than 6 years ago | (#23901949)

That's really not the story. The story is how simple the exploits were and yet, how long it took to be discovered.

Re:The real story (5, Funny)

Anonymous Coward | more than 6 years ago | (#23901979)

sooo... open source failed? that's what it sounds like you're saying. beware of pitchfork carrying moderators ;)

Re:The real story (5, Insightful)

CrazedWalrus (901897) | more than 6 years ago | (#23902191)

How did open source fail? Someone who wasn't the original author had access to the code and found the bugs. How quickly it's found is a function of how many qualified people are looking at the code. I didn't RTFA, but presumably Drew Yao, a member of the security team, was security auditing the code. This activity would have been much harder to impossible with closed source code.

I'd say the system worked as advertised here.

Re:The real story (2, Insightful)

Richard_at_work (517087) | more than 6 years ago | (#23902401)

This activity would have been much harder to impossible with closed source code.

I'd say the system worked as advertised here.

Yup, because Microsoft certainly never have exploits such as these discovered...

Re:The real story (3, Insightful)

CrazedWalrus (901897) | more than 6 years ago | (#23902835)

I didn't say anything about Microsoft. Obviously there are, but the source is much more difficult to obtain. If the source can't be obtained, auditors must use more difficult types of testing, or just hope that the vendor did their job correctly.

My only point was that Apple would have a much more difficult time auditing, say, Office for Mac, than they would with Ruby due to the requirement for source code agreements or using more arcane methods like blackbox testing or disassembly. The same applies to Photoshop, Flash, or any other 3rd party closed-source app.

The victory here is that Ruby was improved by a 3rd party who had ready access to the source. When the source is available, this will happen much more often than when it's not.

Re:The real story (0)

Anonymous Coward | more than 6 years ago | (#23905201)

If we compare apples to apples which in this case would be Ruby to the .Net platform, then you are wrong. The source code is easily viewable with tools like Reflector. Also MS has set up symbol servers so that you can trace through the libraries in a debug environment.

Re:The real story (1)

Waffle Iron (339739) | more than 6 years ago | (#23905435)

Also MS has set up symbol servers so that you can trace through the libraries in a debug environment.

They would reveal their Symbols? The very symbols of their code!? This is truly magnanimous gesture indeed! But alas, I fear I'm not worthy to log into a server of such patrician caliber.

Re:The real story (2, Interesting)

drinkypoo (153816) | more than 6 years ago | (#23903921)

Yup, because Microsoft certainly never have exploits such as these discovered...

The difference is who finds them and what happens when they are found. Vulnerabilities in Microsoft products are found either by accident (I pass you some data which should be valid and you choke, or I pass you some data which should be invalid and you don't choke, or you just crash instead of detecting the invalid data and throwing an exception or local equivalent, which is what you SHOULD do EVERY TIME) or by malicious motherfuckers deliberately looking for the above conditions, or disassembling the code and looking for potential race conditions.

By contrast, bugs in open source products are found by looking at the source code and by the above means. But the difference is that the number of non-malicious individuals looking at the code is far larger. So basically, all the same things happen in both places, but the first person to find the bug is more likely to be altruistic in the open source world; and furthermore, the bug is more likely to be found by an altruist at all (ever) in the open source world. You can be sure that a number of Microsoft bugs have been fixed silently without anyone ever announcing them... Which means only the malicious types know they exist, and people who don't patch unless they feel they have to are exposing vulnerabilites that they have no real way to find out about because they lack the requisite time and/or skills to test for such problems.

Re:The real story (1)

petermgreen (876956) | more than 6 years ago | (#23907359)

I'm sure lots of bugs that have potential security implications get quietly fixed (fixed without a security advisory being sent to the distros) in the opensource world too either because the project has a very tight definition of what they count as a security bug (e.g. insisting on a working code execution exploit before considering a bug a security issue), because the project has no mechnism in place for sending security advisories or simply because the people dealing with the bug don't understand it's security implications. Some may even explicitly cover up security issues. (this is one area where it is virtually impossible for an outsider to distinguish between a mistake and a deliberate act).

Re:The real story (1)

shutdown -p now (807394) | more than 6 years ago | (#23906761)

.NET had at least one exploit which allows execution of arbitrary native code from a verified (i.e., supposedly safe) assembly regardless of CAS restrictions. On the other hand, it's nowhere as trivial as the array and string abuse demonstrated here on Ruby.

Re:The real story (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23902505)

How did open source fail? Someone who wasn't the original author had access to the code and found the bugs. How quickly it's found is a function of how many qualified people are looking at the code. I'd say the system worked as advertised here.
Slight correction -- it's a function of how many qualified and honest people are looking at the code. Now, the skilled but dishonest Russian hacking cartels had a financial incentive to look through the code for security problems; comparatively few security researchers had financial incentives to do so. Are you really sure this is the first time this bug has been discovered? Or just the first time by nice cooperative people who don't exploit it and keep it secret?

Re:The real story (1)

CrazedWalrus (901897) | more than 6 years ago | (#23902897)

That's a good point. I don't claim to be sure of anything except that, had the source not been available, those bugs would probably still exist.

In other words, the lifetime of the bugs is substantially decreased. In closed-source apps, less people can audit it, which necessarily means that there's a smaller pool of nice, cooperative people to find the bug.

The people with a financial incentive will still find exploits like they always do -- open or closed.

Re:The real story (1)

RiotingPacifist (1228016) | more than 6 years ago | (#23904131)

Because dishonest hacking cartels would never look at microsoft source code [slashdot.org] !

Funny how open source always wins... (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23902687)

Case 1: the code has no bugs: "many eyes make for shallow bugs!" everyone chants.

Case 2: the code has bugs which get reported and fixed. "See, this would have taken much longer if the source was closed!" This claim is impossible to verify objectively but is stated as a fact, regardless of how trivial the bugs are.

Re:Funny how open source always wins... (2, Insightful)

Anonymous Coward | more than 6 years ago | (#23903747)

And then there are those of us who just don't give a damn about what other people think, but continue to use open source on both our servers and our desktops not because of what other people claim, but because in our experience it works better.

Re:Funny how open source always wins... (2, Insightful)

Anonymous Coward | more than 6 years ago | (#23903811)

Case 1 is a myth. All software has bugs. Even the best and most thoroughly reviewed code typically at least 1 bug per thousand lines of code. Always. (However, they're not always security related like this.)

Re:Funny how open source always wins... (0)

Anonymous Coward | more than 6 years ago | (#23905999)

Case 1 is a myth. All software has bugs. Even the best and most thoroughly reviewed code typically at least 1 bug per thousand lines of code. Always. (However, they're not always security related like this.)
Even if it is, it doesn't invalidate the point. In fact, it actually strengthens it -- how come the "many eyes" didn't spot the bug? It brings up a harsh truth: how much OSS code is actively reviewed by lots of different people? I know some is, but it seems like this is one area where the idea is far superior to the reality. Not saying it should be abandoned, just viewed with more pragmatism than idealism.

Re:Funny how open source always wins... (1)

Sancho (17056) | more than 6 years ago | (#23904019)

Aaaand then you get people who claim that "Open Source worked!" when a 25 year old bug is squashed.

Re:The real story (1)

Lars T. (470328) | more than 6 years ago | (#23902771)

How did open source fail? Someone who wasn't the original author had access to the code and found the bugs.

Who says he was the first to find the bugs - he's just the first not not use the exploit to crack servers.

Re:The real story (1)

CrazedWalrus (901897) | more than 6 years ago | (#23903509)

I never claimed he was the first. The point was that these were found *quicker* than if it was solely up to the original authors to find the bugs. "Quicker" is a relative term compared to the alternative. It doesn't mean "first", and it doesn't mean "quick".

Re:The real story (0)

Anonymous Coward | more than 6 years ago | (#23906169)

*more quickly*

Re:The real story (4, Insightful)

headLITE (171240) | more than 6 years ago | (#23902259)

A vulnerability in an open source project was found by a third party doing a security audit of the code. The possibility to validate the source code is exactly what open source proponents claim is the reason for open source being more secure. Everybody can have a go, a thousand pairs of eyes see more than one pair, and all that. Try auditing Visual Basic 6 for comparison.

Re:The real story (3, Interesting)

moosesocks (264553) | more than 6 years ago | (#23902501)

Try auditing Visual Basic 6 for comparison.
I don't need to see the source to know that VB6 is completely insecure. The documentation is more than sufficient to prove that the entire language was fundamentally flawed.

Re:The real story (1)

Emb3rz (1210286) | more than 6 years ago | (#23903183)

If 1 = 1 Then End Tell me, oh great Flamebaiter-modded-interesting, how this 'fundamentally flawed' programming language will insecurely compile the above code. The proper order of progression is: Think, Speak.

Re:The real story (1)

geonik (1003109) | more than 6 years ago | (#23904837)

Try auditing Visual Basic 6 for comparison.

Please! Even the lead programmer of the language would feel insulted if asked to do that.

Re:The real story (1)

teknopurge (199509) | more than 6 years ago | (#23902569)

A testament to either how adopted the Ruby language is or the competency of the maintainers.

I'm rally not a troll; I think they are valid points.

Not just RoR (2, Interesting)

Slashdot Parent (995749) | more than 6 years ago | (#23904113)

This reminds me of the notorious suidperl vulnerability [ciac.org] from back in the day. In a nutshell, you could use the following code to achieve a root shell from an unprivileged account (apologies if I don't get it exactly right... I don't have an ancient system to verify on):

#!/usr/bin/suidperl -w
 
$< = 0;
$> = 0;
 
`/bin/bash`;
That was available for how many years? Anyhow, that's much more serious than this Ruby DoS attack. ;)

Re:The real story (4, Insightful)

mccalli (323026) | more than 6 years ago | (#23901967)

The real story here is how quickly the bugs were patched. I'd like to see MS respond half as fast to holes in Windows and it's attendant parts and pieces.

No. The real story here are the security bugs, precisely as described. This isn't cheerleading - to users of Ruby it really doesn't matter how fast some other imagined patch might have come out from another company for a different product. If I'm running Ruby, I need to know that these bugs exist and that patches can be applied for them.

Drop the us vs them thinking - it doesn't help is pretty much just FUD.

Cheers,
Ian

Re:The real story (1)

thePowerOfGrayskull (905905) | more than 6 years ago | (#23905203)

Frankly, it's not reasonable to expect them to - that's like comparing apples to ... Boeing jets. I suspect if the Windows was the size and complexity of Ruby, they'd be able to get fixes out just as quickly.

Confirmation (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23901879)

Confirmation that Ruby simply isn't "enterprise ready".

Re:Confirmation (3, Insightful)

setagllib (753300) | more than 6 years ago | (#23901965)

Then what is? Sun Java and Microsoft .NET have both had long histories of security patches. Python is a lot better but nothing is perfect.

At least with a Linux Python/Ruby you get the security fix within hours as part of your regular operating system update. With Java you have to download the whole thing again from Sun's site. With .NET you have to wait for patch tuesday or apply a hotfix manually.

Re:Confirmation (1)

English French Man (1220122) | more than 6 years ago | (#23902007)

I can only agree to this. Enterprise readyness is difficult to quantify, and nothing is completely bug free.

Now this bug seems pretty basic and important, but then there are (or at least were) bugs like that in a lot of systems, and it is fairly impressive to see that these are corrected in this few a time.

Re:Confirmation (4, Interesting)

larry bagina (561269) | more than 6 years ago | (#23902029)

"Enterprise" means you don't blindly install updates on day 0.

Re:Confirmation (2, Insightful)

headLITE (171240) | more than 6 years ago | (#23902329)

Agreed. It also usually doesn't refer to a programming language or environment. At any rate, "enterprise" applications have historically been written in a bunch of languages that don't do array bounds checking. Granted, ruby is supposed to do it, but I mean, seriously - are kids these days so spoiled by JavaScript and VB that this kind of error is a surprise and the biggest bug ever?

Re:Confirmation (3, Insightful)

Idaho (12907) | more than 6 years ago | (#23903583)

Granted, ruby is supposed to do it, but I mean, seriously - are kids these days so spoiled by JavaScript and VB that this kind of error is a surprise and the biggest bug ever?

1. If the interpreter is supposed to do it, except it then turns out it actually doesn't (or doesn't do it correctly), then yes.
2. If the problem occurs in something that is a part of the language itself, or at least part of its standard library/built-in types, or, however you want to define it, if it is in the set of stuff that everyone who has the language installed has installed, and the functionality is used in pretty much any program ever written in the language, then yes.

So, yes.

Re:Confirmation (5, Funny)

/ASCII (86998) | more than 6 years ago | (#23902371)

No, "Enterprise ready" means they didn't have to deal with that shit on Star Trek.

Re:Confirmation (1)

v1 (525388) | more than 6 years ago | (#23902473)

and I for one get really tired of all the Sun Java updates. One particular update path I have to go through with some machines requires downloading 5 or 6 java updates, at 35-50mb EACH, as java trampolines itself up to the latest version.

Re:Confirmation (2, Insightful)

Anonymous Coward | more than 6 years ago | (#23902647)

Actually, considering its age, Java DOESN'T have a "long" history of security patches. Java was designed by security freaks and the security both of the core language and the standard platforms is extensively vetted and tested by security professionals. Which is why you have to look long and hard for news reports of major security breaches in Java.

The Java system is considered to be an integrated whole and new releases have to pass an extensive suite of tests before they are certified. Yes, it's a royal pain in the [censored] to have to download an entire enormous new release of the runtime engine and support classes, but the upside is that you don't get the kinds of security and reliability issues that come from a mix-match-and-patch approach. There's only a small number of possible configurations to keep clean.

Re:Confirmation (1)

ahabswhale (1189519) | more than 6 years ago | (#23906993)

Sun Java and Microsoft .NET have both had long histories of security patches. Python is a lot better but nothing is perfect.
Really? Please provide stats proving these assertions.

ROFL (1)

yabos (719499) | more than 6 years ago | (#23904683)

Well, Windows has a waaaay worse track record yet it's used by 90+% of businesses.

message to staff at Apple HQ (-1, Flamebait)

Library Spoff (582122) | more than 6 years ago | (#23901973)

Quick, find a hole in something to take the heat off the osX Vuln! nah - not in Vista, something else...

Re:message to staff at Apple HQ (5, Insightful)

LunarCrisis (966179) | more than 6 years ago | (#23902049)

The bugs would have been there even if Apple hadn't found them. Why not thank them for improving the quality of Ruby?

Re:message to staff at Apple HQ (1)

Library Spoff (582122) | more than 6 years ago | (#23902125)

Sorry - forgot the *joke* tag...
Yes they have improved the quality of Ruby by doing this.

Re:message to staff at Apple HQ (4, Insightful)

UnknowingFool (672806) | more than 6 years ago | (#23902759)

Apple finds serious bugs in Ruby. They tell the Ruby developers. Ruby developers issue patches. That's not sensational.

MS finds a bug in Safari. They tell everyone not to use Safari. I see slight differences. :P

Re:message to staff at Apple HQ (1)

SecureThroughObscure (1282782) | more than 6 years ago | (#23904069)

Where exactly did they tell everyone to not use Safari? In fact, I believe that MS reported the vulnerability to Apple and helped them understand why it needs to be fixed.

Re:message to staff at Apple HQ (1)

UnknowingFool (672806) | more than 6 years ago | (#23904343)

In their advisory: [microsoft.com]

Restrict use of Safari as a web browser until an appropriate update is available from Microsoft and/or Apple.

Re:message to staff at Apple HQ (1)

Achromatic1978 (916097) | more than 6 years ago | (#23905227)

What a joke.

Look at almost every security advisory issued out there. "Remedy: Do not/restrict usage of X until bug is resolved".

Making this a stab at MSFT just shows you up as an Apple fanboy.

Muuuuuhahahahahahaha !! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23902025)

Muuuuuhahahahahahaha !! It's so fucking funnny. I don't even know what the fuck ruby is but it's fucking funny with those gaping holes. You lamos need a powerhouse like Microsoft to baby-feed you something a little less FLAAWED !! Dumb-downed is what the doctor orders for you a!!

put on your slippers (0, Offtopic)

Elisanre (1108341) | more than 6 years ago | (#23902041)

and click your heels three times

Re:put on your slippers (-1, Offtopic)

Mushdot (943219) | more than 6 years ago | (#23902079)

oops i modded you by accident ,so posting to un-moderate.

Goes to show ... (2, Insightful)

Qbertino (265505) | more than 6 years ago | (#23902207)

This, IMHO, goes to show that Ruby isn't any better than the other Open Source interpreted languages. Despite what the Ruby fanboys allways claim, it is actually far less mature then, let's say, Python or PHP.
A matured, tested and established mod_ruby, unicode and a few years more in the field is what Ruby needs before I take a look at it.

My 2 cents.

Re:Goes to show ... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23902701)

wanker

Re:Goes to show ... (1, Insightful)

Fweeky (41046) | more than 6 years ago | (#23902813)

PHP had extremely similar holes fairly recently; integer overflows, string length fuckups, etc. In code that was far more obviously hilariously bad; e.g. using float to track string length, and checking an int for > MAX_INT to detect overflow. The initial fixes were similarly hilarious too.

In the mean time, until a couple of days ago half my Ruby services have been up for on the order of 14 months, and will likely do the same for the next 14, though by then there will probably be three or four different VM's to deploy it on instead of just two. Also, our PHP's will probably continue to go into weird unbusy loops, and occasionally crash for no apparant reason.

So, um, how's jPHP and Jython coming along? Would you deploy a real life application on Jython?

Re:Goes to show ... (3, Insightful)

smallpaul (65919) | more than 6 years ago | (#23904235)

So, um, how's jPHP and Jython coming along? Would you deploy a real life application on Jython?

So, um, how's jPHP and Jython coming along? Would you deploy a real life application on Jython?

Go team. Rah! Rah! Rah! YEAH!!!!

But I have two questions:

1. What does the relative merit of Jython versus Jruby have to do with the price of tea in China? Are you moving your apps from the buggy MRI to JRuby this week to avoid these security holes?

2. What evidence do you have that Jruby is more appropriate for "real life applications" than Jython? I know people who have deployed real life applications on Jython since before the first checkin of JRuby. For example, Websphere ships with Jython.

http://wiki.python.org/jython/JythonUsers [python.org]

Ruby has some real advantages over Python. But if you don't know them, don't just make stuff up.

Re:Goes to show ... (1)

Fweeky (41046) | more than 6 years ago | (#23904585)

My question about Jython was not rhetorical; I keep hearing people saying it needs more love. And no, I wouldn't give Java the time of day, but it is perhaps quite relevent to those who worry about wobbly concepts like "maturity" in decade-old languages.

Re:Goes to show ... (1)

krmt (91422) | more than 6 years ago | (#23904931)

Jython is actually getting that love right now. Right around the time Sun hired the JRuby guys they also hired two Jython guys. Jython has a new improved backend and is rapidly approaching a 2.5 release which will bring it up to speed with the current stable CPython. They're going to get to work on py3k compatibility after that. Hopefully they'll be able to achieve parity with CPython within a year or so, but they're definitely making very real progress.

Re:Goes to show ... (0)

Anonymous Coward | more than 6 years ago | (#23904431)

I would recommend Rhino over Jython hands down. Rhino is better performing and is much better supported - including several on Google staff.

Re:Goes to show ... (1, Insightful)

Achromatic1978 (916097) | more than 6 years ago | (#23905257)

is much better supported - including several on Google staff.

The fuck has that to do with anything? "Hey look, people who WORK AT GOOGLE are involved in it, it must be good!"

Re:Goes to show ... (1)

BotnetZombie (1174935) | more than 6 years ago | (#23905015)

We used Jython quite a lot at a company I previously worked for. Real life applications (mostly mobile services), some with 500-1000K hits daily, no special problems with that. Jython has its quirks, but I like it and still use it sometimes for personal projects

Re:Goes to show ... (3, Insightful)

Etherized (1038092) | more than 6 years ago | (#23903095)

Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.

For what it's worth, this appears to be a flaw in the official ruby interpreter. That's a big deal, of course, but just so you know: most people who speak the praises of ruby are talking about the structure of the language, not necessarily the implementation of the interpreter itself. There are alternate implementations of the ruby interpreter that are generally considered to be "better" than Matz's in many ways.

Re:Goes to show ... (2, Informative)

bcrowell (177657) | more than 6 years ago | (#23904861)

Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.

I'd interpret the same facts the other way around. A decade isn't very long for a programming language to mature. Ruby and PHP have both only been around for a decade, so they're not very mature. I do most of my coding in perl, but have done one significant project in ruby, and I can see some advantages and disadvantages of each. If you really like OOP, and/or you have a project that's naturally well suited to the OOP approach, then perl is an extremely awkward language, and ruby is much more natural. However, perl is 21 years old, and the perl 5 implementation is extremely mature. You simply don't run into the kind of implementation bugs in perl that you do in ruby. As a concrete example, my ruby project does a lot of string munging, and I had to choose between using ruby 1.9 in order to get a regex engine that was as full-featured as perl's, or using ruby 1.8. I chose 1.9, and after the project was complete and working well, I started running into cases where the interpreter's regex engine would crash the interpreter. You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability. I've also had ruby code break because of changes in the design of the language, and that has never, ever happened to me with perl. (And before anyone starts up about how perl 6 will break everyone's code, no, it won't. Perl 6 will run perl 5 code in compatibility mode.)

Re:Goes to show ... (3, Insightful)

SanityInAnarchy (655584) | more than 6 years ago | (#23905149)

This, IMHO, goes to show that Ruby isn't any better at security than the other Open Source interpreted languages.
Fixed that for you.

And it never claimed to be. I don't know anyone who uses Ruby because it's more secure. Everyone I know who uses Ruby does so because of the beautiful syntax, pervasive OO, and other things that make it nicer to program in.

far less mature then, let's say, Python or PHP.
Oh, [net-security.org] really? [softpedia.com]

And again, it's not the security. I'm willing to risk having to patch my interpreter like this once in awhile, if it means I'm able to

Keep in mind, this vulnerability is so far only a DoS, and won't necessarily affect most installations. Most people run multiple interpreters serving a single site, each load-balanced to. Knock out one and it'll be restarted, while the other continues to serve content.

Which brings us to your next point...

A matured, tested and established mod_ruby, unicode and a few years more in the field is what Ruby needs before I take a look at it.
Well, let's see -- Unicode has existed, albeit not great, for quite awhile. 1.9 has had Unicode strings from the beginning.

mod_ruby -- you do realize pretty much no one in the Ruby world uses Apache, right? It's all mongrels and nginx... But if you must, there's Passenger. [modrails.com]

a few years more in the field is what Ruby needs before I take a look at it.
Obviously, you really haven't taken a look at it.

good news (4, Funny)

corbettw (214229) | more than 6 years ago | (#23902303)

Now it's time to start calling up all those RoR sites and use this to convince them to switch the Django.

Ruby Security == null (0)

Anonymous Coward | more than 6 years ago | (#23902393)

Bugs this simple shouldn't occur on software like this, especially one which is suppose to be wide spread.
If they can't get something this simple right then what else are they doing wrong?

Re:Ruby Security == null (1)

shagymoe (261297) | more than 6 years ago | (#23903915)

Sorry, spaces are not accepted in variables. Double capitalizing is bad form and it is nil not null.

Re:Ruby Security == null (0)

Anonymous Coward | more than 6 years ago | (#23904027)

Any software this complex is going to have bugs.

The lesson from this is to stick to simple languages with few idiosyncrasies -- like perl.

Someone had to say... (4, Funny)

Hognoxious (631665) | more than 6 years ago | (#23902625)

Ruby - it's the new PHP.

Re:Someone had to say... (0, Flamebait)

Foofoobar (318279) | more than 6 years ago | (#23905355)

Nah... because PHP is actually used EVERYwhere and is the number 4 most popular programming language. RUBY is still just a toy for beginning developers until is solves several inherent problems with the language.

FUD? (2, Insightful)

MarkusQ (450076) | more than 6 years ago | (#23903105)

These vulnerabilities are likely to crop up in just about any average ruby web application. And by 'crop up' I mean 'crop up exploitable from trivial user-specified parameters.'

Huh? Who lets users enter arbitrary integers to index into arrays? Or let's users submit arbitrary loops for execution? Apart from the statement quoted above, what indication is there that any of these would "crop up" in any but the most contrived circumstances?

--MarkusQ

Re:FUD? (1)

profplump (309017) | more than 6 years ago | (#23903365)

The same people that let remote users enter arbitrary data into an SQL query, or who use non-parameterized queries in the first place. Or who set a "logged_in=1" cookie after authentication and check only that value for future verification.

Re:FUD? (1)

lisany (700361) | more than 6 years ago | (#23904193)

Not so bad if you encrypt the cookie data.

Can you elaborate on this? (1)

argent (18001) | more than 6 years ago | (#23904657)

The same people that let remote users enter arbitrary data into an SQL query [...]

You mean "if you're stupid enough to let someone sneak arbitrary Ruby code in via a form, then they can use this complex memory corruption attack instead of just opening up a backdoor shell"? Or what?

Re:Can you elaborate on this? (1)

jellomizer (103300) | more than 6 years ago | (#23907499)

Yes, Yes... Everyone is stupid except for you. You never had made a stupid mistake or had a bug or a volnerability... If not then you haven't coded that much, or you are so carful coding that it takes you 30 times as long to get a project done, thus making you a liability to the company as you cannot differieante the difference between perfection and satisifing.

Lets get real, people make mistakes, we code with for the need sometimes security lacks because they will not pay for such carful actions or put value on security at the time. Or we think something is more secure then it is.

Back in the early 90's buffer overflows wern't considered a security risk just a code stability risk, no one really though that they could execute code threw a buffer overflow predictibly, as well most inputs were just expected from the keyboard directly so they wrote code and made sure they couldn't type more then the keyboard input or say in web development make an input type=text maxlength=12 or something silly like that because at worst it would just error out. Aswell people may not know all the fuctions of the languge and will fall back on other methods and make mistakes. "SELECT * From "+selboxchoise+";". Or the calculation was very complex and security checking got in the way.

Yes there are workarounds to make it more secure. But people make mistakes, smart people make mistakes. If you can get the tool to alltert you when you make a mistake to safly handle the mistake all the better. Saying somone is dumb because their code could have a security problem is rather stupid on your part, as you could be writting volnerable code without realizing it yourself.

Re:FUD? (0)

Anonymous Coward | more than 6 years ago | (#23904943)

Your point is quite valid; I think that a lot of people that commented so far don't even know the difference between a hash and an array.

Re:FUD? (1)

I Want to be Anonymo (1312257) | more than 6 years ago | (#23905657)

The first thing that popped into my head when I saw it was to submit a very long request of some kind.

Overflowing an index with simply a lot of characters might be tough, but if you had knowledge (or at least a concept) of the inner workings of the web app, it might be possible to take advantage of a multiplying effect, where each item of a request could result in some index being incremented not by one, but by 1000 or something.

As an example, maybe a search application would create several entries in a table for each search term (an entry per matching item, perhaps). It might work ok for 10 terms, but 10 million would make it blow up.

Of course, this scenario would indicate a bug in the app, but using a language like Ruby should prevent that kind of error from allowing arbitrary machine code to execute.

This is all sort of vague and hand wavy, but that is because it is just to outline a concept and would vary from case to case.

Re:FUD? (1)

owlstead (636356) | more than 6 years ago | (#23905859)

When we are talking about users and software we are talking about the users of the libraries. Don't think web users here, think applications. Of course, if you don't do any checking you may have users that submit tricky stuff into your application. Anyway, if you are relying on the platform to do certain checks, it might very well be that applications get vulnerable pretty fast.

Re:FUD? (1)

wycats (956943) | more than 6 years ago | (#23906041)

Exactly. Rails, which is built on top of Ruby, doesn't allow arbitrary input as integer keys on Arrays, nor does it allow the user to force-execute a (very) long while loop. The vectors for attacking this vulnerability in Rails is limited to incoming params or POST bodies, and so far nobody has been able to show a vector for using these vulnerabilities to execute remote code or cause a DoS attack on Rails or Merb.

Re:FUD? (1)

shutdown -p now (807394) | more than 6 years ago | (#23906705)

Huh? Who lets users enter arbitrary integers to index into arrays?
You do, every time you make an "Add Item" button on the web page.

WIshful Thinking (0, Troll)

wmbetts (1306001) | more than 6 years ago | (#23903537)

Good maybe it and all the "Web 2.0" assholes will go away with it.

Re:WIshful Thinking (0)

Anonymous Coward | more than 6 years ago | (#23903911)

Would it be to much for me to hope that you'll go away?

Re:WIshful Thinking (1)

wmbetts (1306001) | more than 6 years ago | (#23905465)

Yes. BTW, That post wasn't a troll.

I have patched all of my customer's servers (2, Insightful)

MarkWatson (189759) | more than 6 years ago | (#23903599)

I did some testing on an off line server, and then pushed these patches.

I am concerned about "Ruby the Platform". I have dealt with deployment and scaling issues for a few years on a customer project written in Rails + Common Lisp, and as much as I *love* coding in Ruby and Lisp, this experience has also made me appreciate "Java the platform" :-)

Re:I have patched all of my customer's servers (1)

tcopeland (32225) | more than 6 years ago | (#23903861)

> I have dealt with deployment and scaling issues for a few years

What do you think of modrails [modrails.com] ? To me it changes the Rails deployment game entirely... no more mongrel clusters, no more complicated rewrite rules...

Re:I have patched all of my customer's servers (1)

MarkWatson (189759) | more than 6 years ago | (#23903991)

I have not yet looked at modrails, but I just looked at the site that you linked - looks very interesting - thanks!

That said, I am fairly happy with nginx + memcached + mongrel cluster

Re:I have patched all of my customer's servers (1)

tcopeland (32225) | more than 6 years ago | (#23904791)

No problem! Yup, the thing I like about modrails is that I don't have to allocate my cluster sizes and port ranges and such up front - I can just set RailsMaxPoolSize and then let modrails spin application instances up and down as needed. I used to worry about file uploads - you know, "oh gosh, what if 4 people are uploading files at once, they'll tie up the whole cluster, so let's restrict uploads to just mongrels on ports 8000-8001" - that kind of thing. Nice not to have to worry about that stuff anymore.

+1 on memcached, yeah, great stuff there!

Re:I have patched all of my customer's servers (1)

SanityInAnarchy (655584) | more than 6 years ago | (#23905199)

I actually like mongrel clusters as an exercise in horizontal scaling. The reason I'd consider modrails is that it's somewhat faster.

Remember, once you've got a mongrel cluster -- complete with "complicated" (read: five simple config lines that you copy and paste) rewrite rules -- it's trivial to put a few more mongrels on another machine.

Re:I have patched all of my customer's servers (1)

tcopeland (32225) | more than 6 years ago | (#23905383)

> it's trivial to put a few more mongrels on another machine.

True, and right, once you get all the parts (init scripts, monit, ports, etc) working, it's done. But all that goes away with modrails... just keep Apache running and you're all set. Just a lot fewer moving parts. The horizontal scaling is still there, modrails just removes a layer from the architecture - which is nice...

Re:I have patched all of my customer's servers (1)

SanityInAnarchy (655584) | more than 6 years ago | (#23906907)

But all that goes away with modrails...
In what way?

You still need to setup a reverse proxy to the other servers. The only thing you've done is replaced mongrel with apache.

DoS for ruby? You don't need exploits for that (2, Funny)

Anonmyous Coward (1290620) | more than 6 years ago | (#23907247)

I LOVE ruby as a language, but let's be realistic here. All you need for a DOS attack against a ruby-based web application of any complexity is a few dozen users using it as intended. No need to waste time figuring out complicated exploits for that.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?