Multiple Security Holes In Ruby 1.8, 1.9

← Back to Stories (view on slashdot.org)

Multiple Security Holes In Ruby 1.8, 1.9

Posted by kdawson on Monday June 23, 2008 @12:07AM from the that-ain't-good dept.

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

148 comments

Min score:

Reason:

Sort:

omg by Elisanre · 2008-06-23 00:08 · Score: -1, Offtopic

oh nose, it can't be the first *hide*
Derailed by lemur3 · 2008-06-23 00:09 · Score: 2, Funny

I can see the blood now!
1. Re:Derailed by Anonymous Coward · 2008-06-23 01:30 · Score: 0
  
  Apple on security. Oxymoron ? Maybe they should stick to their own software holes (Carpet bombing anyone?) before they comment on others.
2. Re:Derailed by Lars+T. · 2008-06-23 01:48 · Score: 2, Informative
  
  "Carpet bombing" neither executed arbitrary code nor has it not been fixed.
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
3. Re:Derailed by Anonymous Coward · 2008-06-23 03:15 · Score: 0
  
  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.
4. Re:Derailed by Anonymous Coward · 2008-06-23 03:26 · Score: 0
  
  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.
5. Re:Derailed by Poltras · 2008-06-23 04:35 · Score: 1
  
  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.
  
  --
  Of Code And Men
6. Re:Derailed by Lars+T. · 2008-06-23 05:48 · Score: 2, Insightful
  
  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.
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
The real story by dreamchaser · 2008-06-23 00:19 · Score: -1, Flamebait

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.
1. Re:The real story by Anonymous Coward · 2008-06-23 00:23 · Score: 1, Informative
  
  The bugs found are fairly basic honestly.
  If these were found in any MS product it wouldnt matter how fast they were patched.
2. Re:The real story by JeremyGNJ · 2008-06-23 00:39 · Score: 3, Insightful
  
  That's really not the story. The story is how simple the exploits were and yet, how long it took to be discovered.
3. Re:The real story by mccalli · 2008-06-23 00:41 · Score: 4, Insightful
  
  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
4. Re:The real story by Anonymous Coward · 2008-06-23 00:44 · Score: 5, Funny
  
  sooo... open source failed? that's what it sounds like you're saying. beware of pitchfork carrying moderators ;)
5. Re:The real story by CrazedWalrus · 2008-06-23 01:05 · Score: 5, Insightful
  
  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.
6. Re:The real story by headLITE · 2008-06-23 01:14 · Score: 4, Insightful
  
  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.
7. Re:The real story by Richard_at_work · 2008-06-23 01:24 · Score: 2, Insightful
  
  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...
8. Re:The real story by moosesocks · 2008-06-23 01:32 · Score: 3, Interesting
  
  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.
  
  --
  -- If you try to fail and succeed, which have you done? - Uli's moose
9. Re:The real story by Anonymous Coward · 2008-06-23 01:33 · Score: 5, Insightful
  
  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?
10. Re:The real story by teknopurge · 2008-06-23 01:37 · Score: 1
  
  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.
  
  --
  Website Hosting
11. Re:The real story by Lars+T. · 2008-06-23 01:51 · Score: 1
  
  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.
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
12. Re:The real story by CrazedWalrus · 2008-06-23 01:56 · Score: 3, Insightful
  
  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.
13. Re:The real story by CrazedWalrus · 2008-06-23 02:01 · Score: 1
  
  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.
14. Re:The real story by Emb3rz · 2008-06-23 02:25 · Score: 1
  
  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.
15. Re:The real story by CrazedWalrus · 2008-06-23 02:53 · Score: 1
  
  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".
16. Re:The real story by drinkypoo · 2008-06-23 03:26 · Score: 2, Interesting
  
  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.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
17. Re:The real story by RiotingPacifist · 2008-06-23 03:38 · Score: 1
  
  Because dishonest hacking cartels would never look at microsoft source code!
  
  --
  IranAir Flight 655 never forget!
18. Re:The real story by geonik · 2008-06-23 04:21 · Score: 0
  
  Try auditing Visual Basic 6 for comparison.
  Please! Even the lead programmer of the language would feel insulted if asked to do that.
19. Re:The real story by Anonymous Coward · 2008-06-23 04:46 · Score: 0
  
  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.
20. Re:The real story by thePowerOfGrayskull · 2008-06-23 04:46 · Score: 1
  
  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.
21. Re:The real story by Waffle+Iron · 2008-06-23 05:00 · Score: 1
  
  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.
22. Re:The real story by Anonymous Coward · 2008-06-23 05:51 · Score: 0
  
  *more quickly*
23. Re:The real story by shutdown+-p+now · 2008-06-23 06:23 · Score: 1
  
  .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.
24. Re:The real story by petermgreen · 2008-06-23 07:00 · Score: 1
  
  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).
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
25. Re:The real story by billcopc · 2008-06-23 07:43 · Score: 1
  
  Yes, even more so with the mindless popularity of Ruby among the programming anti-elite. The thousands of tutorial screencasts teaching non-programmers "how to build a blog in 5 lines" have led to an explosion of horrible sites that every self-respecting coder and/or security analyst dismissed as a big gaping hole.
  As it turns out, we were right. How these obvious flaws weren't spotted sooner, that's the true mystery.
  
  --
  -Billco, Fnarg.com
26. Re:The real story by Anonymous Coward · 2008-06-23 11:12 · Score: 0
  
  Bite my shiny metal ass. :-P
27. Re:The real story by mibus · 2008-06-23 19:36 · Score: 1
  
  I'd wager that VB6 is probably fairly safe.
  Fundamentally flawed language in many ways, definitely :). But probably fairly safe.
28. Re:The real story by Lodragandraoidh · 2008-06-25 01:09 · Score: 1
  
  It is more complex than that. FOSS does not guarantee a given project will be examined - it only provides the opportunity.
  Other factors determine the extent of examination: popularity, criticality, etc.
  The Linux kernel and Firefox are regularly combed and bugs reported because they are both popular and critical infrastructure.
  There are many more projects that don't get combed as often or as thoroughly, and there are legion that don't get examined at all. Ruby falls in here somewhere.
  
  --
  
  Lodragan Draoidh
  The more you explain it, the more I don't understand it. - Mark Twain
Confirmation by Anonymous Coward · 2008-06-23 00:26 · Score: -1, Troll

Confirmation that Ruby simply isn't "enterprise ready".
1. Re:Confirmation by setagllib · 2008-06-23 00:40 · Score: 3, Insightful
  
  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.
  
  --
  Sam ty sig.
2. Re:Confirmation by English+French+Man · 2008-06-23 00:48 · Score: 1
  
  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.
  
  --
  If I'm wrong, please correct me ; learning is better than being right.
3. Re:Confirmation by larry+bagina · 2008-06-23 00:51 · Score: 4, Interesting
  
  "Enterprise" means you don't blindly install updates on day 0.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
4. Re:Confirmation by headLITE · 2008-06-23 01:19 · Score: 2, Insightful
  
  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?
5. Re:Confirmation by /ASCII · 2008-06-23 01:22 · Score: 5, Funny
  
  No, "Enterprise ready" means they didn't have to deal with that shit on Star Trek.
  
  --
  Try out fish, the friendly interactive shell.
6. Re:Confirmation by v1 · 2008-06-23 01:29 · Score: 1
  
  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.
  
  --
  I work for the Department of Redundancy Department.
7. Re:Confirmation by Anonymous Coward · 2008-06-23 01:45 · Score: 2, Insightful
  
  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.
8. Re:Confirmation by Idaho · 2008-06-23 02:59 · Score: 3, Insightful
  
  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.
  
  --
  Every expression is true, for a given value of 'true'
9. Re:Confirmation by ahabswhale · 2008-06-23 06:36 · Score: 1
  
  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.
  
  --
  Are agnostics skeptical of unicorns too?
10. Re:Confirmation by petermgreen · 2008-06-23 07:48 · Score: 1
  
  what system is this? At least on windows I have never had a problem just downloading the latest java installer from sun and running it regardless of what if any version of sun java was on the machine before.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
11. Re:Confirmation by FooBarWidget · 2008-06-23 09:11 · Score: 2, Funny
  
  Oh yes it is.
12. Re:Confirmation by Lars+T. · 2008-06-23 09:20 · Score: 1
  
  "Enterprise" means you don't blindly install updates on day 0. IOW "Enterprise" means you are vulnerable at least 0-day plus one.
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
13. Re:Confirmation by setagllib · 2008-06-23 13:35 · Score: 1
  
  It's even easier in Linux... just unpack the archive and move the resulting JDK/JRE directory to where you want it. But that's still a lot more fuss than getting it as part of the system update as you do with the "open" platforms. That's another reason OpenJDK is so welcome.
  
  --
  Sam ty sig.
14. Re:Confirmation by setagllib · 2008-06-23 13:37 · Score: 1
  
  Um, what? Can't you just look at the disclosures? Why do I have to spoonfeed you the facts? Are you seriously suggesting even one of the mentioned platforms has had a flawless security record?
  
  --
  Sam ty sig.
15. Re:Confirmation by ahabswhale · 2008-06-23 15:09 · Score: 1
  
  You asserted that Python has a glowing security record compared to Java and .NET. I don't buy it. Prove it. You state things as facts with zero evidence to back it up. In the future, I suggest you not make such assertions unless you can back it up when someone calls you on it. For the record, I will call you on it every time.
  
  --
  Are agnostics skeptical of unicorns too?
16. Re:Confirmation by Allador · 2008-06-23 18:40 · Score: 1
  
  You're exaggerating the risk of the Java JVM and particularly .NET quite a bit.
  If you look at the security hole history of .NET 1.1, .NET 2.0, and .NET 3.0, you'll notice an almost perfect history.
  The only true easy own your box was the JPEG parsing vuln that affected a ton of MS products, and that hit .NET as well, due to shared code/modules.
  The JVM has been less close to perfect, but its not too bad. You can read about them for JRE 1.4, JRE 1.5/5, and JRE 1.6/6.
  I would also say that its not an apples to apples comparison. Most of the vulns in .NET and Java have been not in the core language itself, but in the web-applet piece, or in image handling or similar parts of the libraries built in. These are much larger than the built-in libraries that Python ships with.
  I'm not trying to start an argument of who has the most possible libraries, including 3rd party, but just pointing out that the default shipment of Java and .NET comes with alot more 'stuff', which widens the attack surface area.
17. Re:Confirmation by Allador · 2008-06-23 18:46 · Score: 1
  
  I think you need to look at the disclosure histories yourself.
  Assuming all things are equal, .NET has by far the best record. Python in the middle (by raw count), and Java at the end.
  Mind you, Python has two 'own your system' unpatched vulnerabilities right now, that are between 6 and 9 months old and still unpatched. They could be less serious than secunia makes them out to be, however, I'm not familiar enough with them to say off the top of my head.
  Python 2.3.x
  Python 2.4.x
  Python 2.5.x
  Python 2.6.x
  I'm not going to do it again here, but I also looked at and linked to the secunia listings of .NET and Java in a post just above here. .NET has an excellent record. Java less so, but still not terrible.
message to staff at Apple HQ by Library+Spoff · 2008-06-23 00:43 · Score: -1, Flamebait

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

--
Acid House saves Souls
1. Re:message to staff at Apple HQ by LunarCrisis · 2008-06-23 00:54 · Score: 5, Insightful
  
  The bugs would have been there even if Apple hadn't found them. Why not thank them for improving the quality of Ruby?
  
  --
  Mr. Period: Nine is the one that's right by ten!
  Nine: One day I will kill him. Then, I will be Ten.
2. Re:message to staff at Apple HQ by Library+Spoff · 2008-06-23 01:00 · Score: 1
  
  Sorry - forgot the *joke* tag...
  Yes they have improved the quality of Ruby by doing this.
  
  --
  Acid House saves Souls
3. Re:message to staff at Apple HQ by UnknowingFool · 2008-06-23 01:50 · Score: 4, Insightful
  
  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
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
4. Re:message to staff at Apple HQ by SecureThroughObscure · 2008-06-23 03:34 · Score: 1
  
  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.
5. Re:message to staff at Apple HQ by UnknowingFool · 2008-06-23 03:49 · Score: 1
  
  In their advisory:
  Restrict use of Safari as a web browser until an appropriate update is available from Microsoft and/or Apple.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
6. Re:message to staff at Apple HQ by Achromatic1978 · 2008-06-23 04:48 · Score: 1
  
  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.
7. Re:message to staff at Apple HQ by Lars+T. · 2008-06-23 09:25 · Score: 2, Insightful
  
  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.
  Ignoring that there is a much bigger hole in IE that the Apple bug makes a tiny bit easier to trigger shows you up as what then?
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
8. Re:message to staff at Apple HQ by Allador · 2008-06-23 18:54 · Score: 1
  
  Nice job with the random hyperbole there.
  Lets report on this more accurately:
  Apple finds serious bugs in Ruby. They tell the Ruby developers. Ruby developers issue patches.
  MS finds a bug in Safari. They tell the Apple developers. Apple developers say they wont patch it soon. MS then tells everyone not to use Safari until its fixed. You're right in that its not the same situation, but when you put all the facts in, rather than trying to cast a one-sided light on the situation, its alot clearer.
  PS, the funky quoting style is slashdot's recent bugfest that ignores hard returns thats cropped up lately.
9. Re:message to staff at Apple HQ by Allador · 2008-06-23 18:58 · Score: 1
  
  Ignoring that there is a much bigger hole in IE that the Apple bug makes a tiny bit easier to trigger I would disagree as to which one is the bigger hole.
  Anything that lets arbitrary attackers write arbitrary files to protected locations on the local system is worse than IE loading DLLs from known locations.
  Why? Simply because if you're able to write files to the computer (outside of cookies and temp) just by having someone visit a website then you've largely owned the computer at that point.
  The only thing that restricts the scope of the apple bug is that it only writes to the desktop (which is a stupid auto-download location).
  IE's issue with loading DLL's IS stupid, but by itself is a complete non-issue.
  Whereas Apple's bug by itself is still problematic.
  To be fair though, MS IE has had a very turbulent history when it comes to drive-by file dropping onto the local system. But in this specific case, I would disagree with your statement.
10. Re:message to staff at Apple HQ by Lars+T. · 2008-06-24 02:15 · Score: 1
  
  Ignoring that there is a much bigger hole in IE that the Apple bug makes a tiny bit easier to trigger I would disagree as to which one is the bigger hole.
  Anything that lets arbitrary attackers write arbitrary files to protected locations on the local system is worse than IE loading DLLs from known locations.
  You would have an argument if the Desktop were a "protected location" - it isn't.
  
  --
  Lars T.
  To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Muuuuuhahahahahahaha !! by Anonymous Coward · 2008-06-23 00:50 · Score: -1, Flamebait

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 by Elisanre · 2008-06-23 00:52 · Score: -1, Offtopic

and click your heels three times
1. Re:put on your slippers by Mushdot · 2008-06-23 00:56 · Score: -1, Offtopic
  
  oops i modded you by accident ,so posting to un-moderate.
Goes to show ... by Qbertino · 2008-06-23 01:08 · Score: 2, Insightful

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.

--
We suffer more in our imagination than in reality. - Seneca
1. Re:Goes to show ... by Anonymous Coward · 2008-06-23 01:48 · Score: -1, Troll
  
  wanker
2. Re:Goes to show ... by Fweeky · 2008-06-23 01:54 · Score: 1, Insightful
  
  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?
3. Re:Goes to show ... by yogikoudou · 2008-06-23 02:14 · Score: 2
  
  I believe this is the PHP bug you mention: http://use.perl.org/~Aristotle/journal/33448 .
4. Re:Goes to show ... by Etherized · 2008-06-23 02:19 · Score: 3, Insightful
  
  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.
5. Re:Goes to show ... by smallpaul · 2008-06-23 03:43 · Score: 3, Insightful
  
  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
  Ruby has some real advantages over Python. But if you don't know them, don't just make stuff up.
6. Re:Goes to show ... by Anonymous Coward · 2008-06-23 03:54 · Score: 0
  
  I would recommend Rhino over Jython hands down. Rhino is better performing and is much better supported - including several on Google staff.
7. Re:Goes to show ... by Fweeky · 2008-06-23 04:05 · Score: 1
  
  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.
8. Re:Goes to show ... by bcrowell · 2008-06-23 04:23 · Score: 2, Informative
  
  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.)
  
  --
  Find free books.
9. Re:Goes to show ... by krmt · 2008-06-23 04:27 · Score: 1
  
  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.
  
  --
  
  "I may not have morals, but I have standards."
10. Re:Goes to show ... by BotnetZombie · 2008-06-23 04:32 · Score: 1
  
  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
11. Re:Goes to show ... by SanityInAnarchy · 2008-06-23 04:42 · Score: 3, Insightful
  
  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, really?
  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.
  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.
  
  --
  Don't thank God, thank a doctor!
12. Re:Goes to show ... by Achromatic1978 · 2008-06-23 04:50 · Score: 1, Insightful
  
  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!"
13. Re:Goes to show ... by Anonymous Coward · 2008-06-23 07:39 · Score: 0
  
  get a clue - it means they're paying developers to work on Rhino fulltime - including the person who originally WROTE Rhino.
14. Re:Goes to show ... by belmolis · 2008-06-23 08:18 · Score: 1
  
  You can also use a still more mature language such as Tcl. Tcl has to my knowledge had next to no security vulnerabilities in recent years and has a very high quality codebase.
15. Re:Goes to show ... by vmalloc_ · 2008-06-23 14:16 · Score: 1
  
  self.__this_is_not_a_good_way_to_call_private_instance_variables
16. Re:Goes to show ... by RAMMS+EIN · 2008-06-24 01:46 · Score: 1
  
  ``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 agree with everything you say, but this part is slightly off. The only way not to have to make that choice is if you don't have it. Maturity of the language (or the implementation, in this case) doesn't factor into it, because the code for new features will invariably be less mature than older code, regardless of how mature the rest of the implementation is.
  
  --
  Please correct me if I got my facts wrong.
17. Re:Goes to show ... by Lodragandraoidh · 2008-06-25 01:22 · Score: 1
  
  Outstanding! Now I won't have to port my python code to java to make IT happy. Now that Java is going FOSS - I wonder how their 'don't use open source' policy is going to fly?
  
  --
  
  Lodragan Draoidh
  The more you explain it, the more I don't understand it. - Mark Twain
good news by corbettw · 2008-06-23 01:17 · Score: 4, Funny

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

--
God invented whiskey so the Irish would not rule the world.
Ruby Security == null by Anonymous Coward · 2008-06-23 01:24 · Score: 0

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?
1. Re:Ruby Security == null by shagymoe · 2008-06-23 03:25 · Score: 1
  
  Sorry, spaces are not accepted in variables. Double capitalizing is bad form and it is nil not null.
2. Re:Ruby Security == null by Anonymous Coward · 2008-06-23 03:31 · Score: 0
  
  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... by Hognoxious · 2008-06-23 01:42 · Score: 4, Funny

Ruby - it's the new PHP.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
1. Re:Someone had to say... by Foofoobar · 2008-06-23 04:56 · Score: 0, Flamebait
  
  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.
  
  --
  This is my sig. There are many like it but this one is mine.
Funny how open source always wins... by Anonymous Coward · 2008-06-23 01:47 · Score: 5, Insightful

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.
1. Re:Funny how open source always wins... by Anonymous Coward · 2008-06-23 03:11 · Score: 2, Insightful
  
  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.
2. Re:Funny how open source always wins... by Anonymous Coward · 2008-06-23 03:17 · Score: 2, Insightful
  
  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.)
3. Re:Funny how open source always wins... by Sancho · 2008-06-23 03:31 · Score: 1
  
  Aaaand then you get people who claim that "Open Source worked!" when a 25 year old bug is squashed.
4. Re:Funny how open source always wins... by Anonymous Coward · 2008-06-23 05:39 · Score: 0
  
  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.
5. Re:Funny how open source always wins... by Draek · 2008-06-23 15:54 · Score: 1
  
  In which world does "shallow" equal "non-existant"? seriously, go inform yourself, AC, and you'll see that the so-called Linus' law (which you incorrectly quoted on your first case) is simply a way to explain the reasoning behind the quote on your second case. And if you want to know the reasoning behind said law (a must if you plan on criticizing it), go read "the Cathedral and the Bazaar" by Eric Raymond.
  
  --
  No problem is insoluble in all conceivable circumstances.
6. Re:Funny how open source always wins... by Anonymous Coward · 2008-06-25 01:02 · Score: 0
  
  Ruby itself is only 13 years old. Additionally, not knowing the release history of Ruby - it is conceivable that these bugs were introduced more recently.
  I get the feeling you are an embittered Microsoftie...am I right?
7. Re:Funny how open source always wins... by Sancho · 2008-06-25 01:53 · Score: 1
  
  Ruby itself is only 13 years old. I was referring to the 25 year old BSD bug that Slashdot reported on not to long ago. There were people who honestly said that this was Open Source at work.
  I get the feeling you are an embittered Microsoftie...am I right? Not at all. At work I use OS X. For servers, I use FreeBSD. At home, I use Linux.
  What I am is sick and tired of zealotry. There are times when open source is great, but every time a major bug is found and fixed, that's not "a victory for open source". And OS X isn't inherently more secure than other major operating systems. But time and again, people spout off these factoids, due either to anecdotal evidence or just plain parroting.
FUD? by MarkusQ · 2008-06-23 02:19 · Score: 2, Insightful

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
1. Re:FUD? by profplump · 2008-06-23 02:41 · Score: 1
  
  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.
2. Re:FUD? by lisany · 2008-06-23 03:41 · Score: 1
  
  Not so bad if you encrypt the cookie data.
3. Re:FUD? by Anonymous Coward · 2008-06-23 04:29 · Score: 0
  
  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.
4. Re:FUD? by I+Want+to+be+Anonymo · 2008-06-23 05:13 · Score: 1
  
  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.
  
  --
  Anonymous Cowards get no respect.
5. Re:FUD? by owlstead · 2008-06-23 05:29 · Score: 1
  
  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.
6. Re:FUD? by wycats · 2008-06-23 05:41 · Score: 1
  
  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.
7. Re:FUD? by shutdown+-p+now · 2008-06-23 06:20 · Score: 1
  
  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.
8. Re:FUD? by RAMMS+EIN · 2008-06-24 00:16 · Score: 1
  
  Yes. Similarly, problems could conceivably occur if you submitted an URL with very many parameters, or a very long one.
  But look at the magnitude required. You need an index of over 2^30 to trigger the problem. That's over a billion entries. To make an HTTP request that long, you would need to send over a gigabyte of data to the server. To encode that many parameters in the URL would require even larger volumes. And to cause your "add item" functionality to trigger the bug would require even larger volumes of data - you would need on the order of a billion requests.
  Don't get me wrong, these are serious bugs that need to be fixed, but "exploitable from trivial user-specified parameters [in web applications]" is a bit rich.
  Also worth noting is that proper checking _is_ performed in some cases:
  $ irb irb(main):001:0> a = [] => [] irb(main):002:0> a[(1 << 31) -1] => nil irb(main):003:0> a[(1 << 31)] RangeError: bignum too big to convert into `long' from (irb):3:in `[]' from (irb):3 from :0 irb(main):004:0> a[(1 << 31)] = ?f RangeError: bignum too big to convert into `long' from (irb):4:in `[]=' from (irb):4 from :0 irb(main):005:0> a[(1 << 31) - 1] = ?f (irb):5: [BUG] Segmentation fault ruby 1.8.5 (2006-08-25) [i486-linux] zsh: abort irb
  So, when _reading_ from the array, all is well. When the index is so large it doesn't fit in a 32-bit signed integer without wrapping around, all is well. But the problem is when _writing_ to an index that is large, but not so large as to be outright rejected.
  Interesting.
  I would venture to guess that they did an honest job of checking for problems with loss of precision (hence the exceptions when a too-large index is used), but didn't really consider all the operations that are performed with a finite-precision number once you have one. For example, if the actually memory address of an array element were "base address + couple of words + index", then that could end up causing integer overflow, even when the index is less than 2^31.
  
  --
  Please correct me if I got my facts wrong.
WIshful Thinking by wmbetts · 2008-06-23 02:55 · Score: 0, Troll

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

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
1. Re:WIshful Thinking by Anonymous Coward · 2008-06-23 03:25 · Score: 0
  
  Would it be to much for me to hope that you'll go away?
2. Re:WIshful Thinking by wmbetts · 2008-06-23 05:01 · Score: 1
  
  Yes. BTW, That post wasn't a troll.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
I have patched all of my customer's servers by MarkWatson · 2008-06-23 02:59 · Score: 2, Insightful

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" :-)
1. Re:I have patched all of my customer's servers by tcopeland · 2008-06-23 03:20 · Score: 1
  
  > I have dealt with deployment and scaling issues for a few years
  What do you think of modrails? To me it changes the Rails deployment game entirely... no more mongrel clusters, no more complicated rewrite rules...
  
  --
  The Army reading list
2. Re:I have patched all of my customer's servers by MarkWatson · 2008-06-23 03:29 · Score: 1
  
  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
3. Re:I have patched all of my customer's servers by tcopeland · 2008-06-23 04:19 · Score: 1
  
  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!
  
  --
  The Army reading list
4. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-06-23 04:46 · Score: 1
  
  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.
  
  --
  Don't thank God, thank a doctor!
5. Re:I have patched all of my customer's servers by tcopeland · 2008-06-23 04:58 · Score: 1
  
  > 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...
  
  --
  The Army reading list
6. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-06-23 06:32 · Score: 1
  
  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.
  
  --
  Don't thank God, thank a doctor!
7. Re:I have patched all of my customer's servers by tcopeland · 2008-06-23 07:14 · Score: 1
  
  > You still need to setup a reverse proxy to the other servers.
  > The only thing you've done is replaced mongrel with apache.
  Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary. Plus, you don't need something watching and restarting each worker. Also, you could conceivably remove a layer from your server architecture - rather than:
  load balancer web app db
  we can have:
  load balancer app db
  And you're not setting up a mod_proxy_balancer pool, just a simple proxy entry. Rather nice!
  
  --
  The Army reading list
8. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-06-25 13:08 · Score: 1
  
  Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary. Given two cores, I'm not sure where more than three mongrels would help. Also, there are several projects which do this already, in several ways.
  Plus, you don't need something watching and restarting each worker. Actually, you do -- it's called Apache+modrails. The only difference is that it's marginally more visible when used as mongrel_cluster.
  Also, you could conceivably remove a layer from your server architecture Not the way you're describing -- or at least, not on more than one app server. Or how does Apache distribute tasks to workers on other machines?
  My cluster right now is: nginx -> mongrels (with rails) -> db
  With modrails, it'd be: nginx -> apache (with modrails) -> db
  Or, the way you'd probably do it: apache (with mod_proxy_balancer) -> apache (with modrails) -> db
  Of course, if you're running on a single machine, it's slightly easier -- then you can drop the nginx/balancer layer.
  
  --
  Don't thank God, thank a doctor!
9. Re:I have patched all of my customer's servers by tcopeland · 2008-06-25 13:34 · Score: 1
  
  > Given two cores, I'm not sure where
  > more than three mongrels would help
  Hm, but isn't that assuming that they're CPU bound? I'd think they'd be more likely to be I/O or socket bound, especially if they're dealing with file uploads or calls to S3 or Salesforce or any other long-lasting requests.
  > Actually, you do -- it's called Apache+modrails. The only
  > difference is that it's marginally more visible when used as mongrel_cluster.
  Right, and modrails handles that, so I don't need to see anything else up as a watchdog.
  > My cluster right now is: nginx -> mongrels (with rails) -> db
  Ah, ok, so nginx is the load balancer.
  > With modrails, it'd be: nginx -> apache (with modrails) -> db
  Yup, right on. The nice thing is that I wouldn't need to have nginx know how many mongrel instances were on each host; instead, I just point it to port 80 on each app server and let modrails handle the cluster size based on the current load.
  > if you're running on a single machine
  Quite right, yup, then it's just like a PHP app - set up Apache, set up the DB, and away you go.
  
  --
  The Army reading list
10. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-06-28 06:39 · Score: 1
  
  I'd think they'd be more likely to be I/O or socket bound, especially if they're dealing with file uploads or calls to S3 or Salesforce or any other long-lasting requests.
  In cases like these, it seems like you'd more often be looking to background the task.
  
  Right, and modrails handles that, so I don't need to see anything else up as a watchdog.
  At the top of deploy.rb:
  require 'mongrel_cluster/recipes'
  And, once:
  gem install mongrel_cluster
  Done. Considerably easier than configuring Apache, I'll bet.
  
  Ah, ok, so nginx is the load balancer.
  Yes. Incidentally, it's also the webserver for static files, for things we don't have on S3.
  
  The nice thing is that I wouldn't need to have nginx know how many mongrel instances were on each host; instead, I just point it to port 80 on each app server and let modrails handle the cluster size based on the current load.
  Interesting. Out of curiosity, what would scaling the cluster size down accomplish? We're pretty much putting apps on dedicated app servers on EC2. We might put memcached on them, but that can't really be resized on the fly.
  
  Quite right, yup, then it's just like a PHP app - set up Apache, set up the DB, and away you go.
  If I wanted something like a PHP app, I'd grab Sinatra, or maybe Camping.
  
  --
  Don't thank God, thank a doctor!
11. Re:I have patched all of my customer's servers by tcopeland · 2008-06-28 09:10 · Score: 1
  
  > In cases like these, it seems like you'd more
  > often be looking to background the task.
  I guess I'm thinking of thing like a 2-3 second call to a service. With mongrel, that's one member of the cluster that's used up for the duration of that call. With modrails, Apache will just start up another worker as needed.
  > gem install mongrel_cluster
  I guess here I was thinking of something like monit or god to watch the individual cluster member and restart them as needed. I didn't think the mongrel_cluster gem did any of that...
  > Out of curiosity, what would scaling the cluster size down accomplish?
  > We're pretty much putting apps on dedicated app servers on EC2.
  You're right, in that situation a dynamically resizable cluster may not buy you anything.
  > If I wanted something like a PHP app, I'd grab Sinatra, or maybe Camping.
  Camping's fun stuff; another fine piece of work from _why...
  
  --
  The Army reading list
12. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-06-30 16:18 · Score: 1
  
  I guess I'm thinking of thing like a 2-3 second call to a service.
  Still something that might be better backgrounded -- though I see your point. Easier to just let a thread be used.
  
  Camping's fun stuff; another fine piece of work from _why...
  If you like Camping, you'll love Sinatra. Not MVC, but still awesome.
  
  --
  Don't thank God, thank a doctor!
13. Re:I have patched all of my customer's servers by tcopeland · 2008-06-30 16:23 · Score: 1
  
  > If you like Camping, you'll love Sinatra. Not MVC, but still awesome.
  Cool, I had seen a couple of RubyForge news items float by but never looked at it, maybe I will now, thanks!
  
  --
  The Army reading list
14. Re:I have patched all of my customer's servers by SanityInAnarchy · 2008-07-02 08:48 · Score: 1
  
  Let me seal it for you:
  
  get '/' do 'Hello, world!' end
  
  It's a REST server in a DSL.
  
  --
  Don't thank God, thank a doctor!
15. Re:I have patched all of my customer's servers by tcopeland · 2008-07-02 23:42 · Score: 1
  
  NICE!
  
  --
  The Army reading list
Not just RoR by Slashdot+Parent · 2008-06-23 03:37 · Score: 2, Interesting

This reminds me of the notorious suidperl vulnerability 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. ;)

--
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
1. Re:Not just RoR by Allador · 2008-06-23 18:23 · Score: 1
  
  I'm not sure that I agree that the perl thing is more serious.
  This is an integer overflow bug, which allows someone to write arbitrary code to arbitrary points in memory.
  It's just a short matter of time before that is 'weaponized' as TFA puts it, and shellcode inserts are achieved through this.
  At this point, this is a remote, instantly-own-your-box without requiring any user access to it at all.
  The suidperl issue is a priv escalation, which means you have to have an unpriv'd account in the first place. The Ruby one doesnt require that.
  Mind you, the ruby holes havent been 'weaponized' yet publicly, but there are a lot of black hats with alot of experience using integer overflow bugs into own your box exploits.
2. Re:Not just RoR by Slashdot+Parent · 2008-06-24 01:54 · Score: 1
  
  I'm not sure that I agree that the perl thing is more serious. Well, I think that's just going to have to go down to the definition of "serious".
  The perl hole was:
  1. trivial to exploit
  2. yielded a root shell
  3. wouldn't be super hard to exploit remotely if you think of all the perl CGI that was written back in 1996. Getting write access to a cgi-bin directory was not considered too challenging.
  4. perl was ubiquitous back then. Installed on most any *nix machine.
  The ruby hole:
  1. has not yet been shown to execute arbitrary code
  2. is definitely remotely exploitable
  3. can only execute code as the owner of the ruby interpreter (probably 'nobody') so hopefully that user can't to anything very interesting
  4. ruby doesn't have much market share right now. How many boxes have a ruby interpreter? How many hosts have RoR? This isn't a sleight against RoR at all, but you have to admit that it represents a small percentage of websites.
  Look at the exploit code in the linked article. I mean, ary[0x7fffffff] = "A" ? C'mon. Who takes an array index from user input? I can't imagine that's a common coding technique.
  I dunno. I think they're both serious. But I think the perl hole was seriouser. ;)
  
  --
  They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Can you elaborate on this? by argent · 2008-06-23 04:10 · Score: 1

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?
1. Re:Can you elaborate on this? by jellomizer · 2008-06-23 07:09 · Score: 1
  
  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.
  
  --
  If something is so important that you feel the need to post it on the internet... It probably isn't that important.
ROFL by yabos · 2008-06-23 04:13 · Score: 1

Well, Windows has a waaaay worse track record yet it's used by 90+% of businesses.
1. Re:ROFL by Allador · 2008-06-23 18:49 · Score: 1
  
  Comparing Python to Windows is a bit silly.
  A more relevant comparison would be .NET to Python. I think you'll find that .NET fares quite well in that comparison, at least according to the information at Secunia.
DoS for ruby? You don't need exploits for that by Anonmyous+Coward · 2008-06-23 06:52 · Score: 2, Funny

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.
1. Re:DoS for ruby? You don't need exploits for that by Anonymous Coward · 2008-06-23 07:29 · Score: 0
  
  Riiight. 'cause, say, Penny Arcade only gets a few dozen visitors at a time.
  GTFO, troll.
2. Re:DoS for ruby? You don't need exploits for that by MyDixieWrecked · 2008-06-23 13:00 · Score: 1
  
  I think you're talking about Rails. Ruby as a web language can be very fast, especially with fcgi or using mongrel as the webserver.
  Rails is "slow" because of all the automagic things it does, but it is possible to create a fast and responsive rails application even when it gets heavy users.
  Twitter is a perfect example of this.
  
  --
  
  ...spike
  Ewwwwww, coconut...
You don't need an exploit if you're already in... by argent · 2008-06-23 08:21 · Score: 1

Everyone is stupid except for you. You never had made a stupid mistake or had a bug or a volnerability.
Oh no, I've been stupid, often enough. I'll happily admit that, because concentrating on the "stupid" but is completely missing the point.
The point isn't that it's stupid to worry about buffer overflows.
The point is that the mechanism you're talking about, code injection attacks similar to the SQL injection attacks, don't need buffer overflows. Because once you've pulled a Ruby code injection attack you've already got full control. It's like the skit about the burglar who needs a knife, so he opens the kitchen door of the house he's breaking into, grabs a knife, then goes back out to work on the window he's trying to lever open...
Mindless popularity? by jotaeleemeese · 2008-06-23 08:36 · Score: 1

Maybe it is popular because it is easy?
If the programming elite are so clever they would have come up with something that allow developers to prototype and put in production things quickly.
You may be right in regards to security, but patronizing people about how they are trying to fulfil a real practical need is frankly beyond the pale.

--
IANAL but write like a drunk one.
Technical merit is not a popularity contest. by jotaeleemeese · 2008-06-23 08:41 · Score: 1

Basic, COBOL and Visual Basic at some point were all the most popular languages (shudder).
And as always, ruby detractors keep to themselves those catastrophic inherent problems that are glaringly obvious ....

--
IANAL but write like a drunk one.
1. Re:Technical merit is not a popularity contest. by Foofoobar · 2008-06-24 11:20 · Score: 1
  
  Not really. Everyone points out the problems with Ruby; Ruby fanbois just choose to be in denial regardless of how many companies and developers post that they have dumped Ruby because of those flaws.
  
  --
  This is my sig. There are many like it but this one is mine.
Proc.kill_troll by refactored · 2008-06-23 12:26 · Score: 1

RUBY is still just a toy for beginning developers until is solves several inherent problems with the language.
Yip, the number one problem in Ruby today is the sheer number of trolls it attracts.
Fortunately I hear Matz is going to make Proc.kill_troll part of the standard library in the next release.
1. Re:Proc.kill_troll by Foofoobar · 2008-06-25 02:02 · Score: 1
  
  hmmm... maybe he should make Proc.deny_truth as well as it would be equally helpful to the Ruby community.
  
  --
  This is my sig. There are many like it but this one is mine.
How so? by MarkusQ · 2008-06-23 15:02 · Score: 1

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.

How so? What array? Where does the user specify the integer? Where in the code is this indexing done (I assmue you're talking about Rails, unless you're just blowing smoke)? On the face of it, your claim here makes no sense.
--MarkusQ
From +2 insightfull up to +5, down to +1 up to +2 by Qbertino · 2008-06-23 22:33 · Score: 1

My Parent is getting modded all the way up and down the scale.
Looks like I struck a cord right there. Hehe.
Flamewar-A-GoGo!

--
We suffer more in our imagination than in reality. - Seneca
What vegetable modded that interesting? by Anonymous Coward · 2008-06-25 03:26 · Score: 0

Broad, very broad claims backed up by no evidence at all. Parent doesn't need any evidence to claim that "VB6 is completely insecure". Not just insecure mind you, no: completely insecure. There's apparently no VB6 statement thinkable that will compile to something without security holes. *rolls eyes* And oh, don't forget that "the entire language was fundamentally flawed". That's right - no single statement does what it's supposed to and all the people who loved the language should be locked up in an insane asylum.