Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

Multiple Security Holes In Ruby 1.8, 1.9 148

Posted by kdawson 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."
This discussion has been archived. No new comments can be posted.

Multiple Security Holes In Ruby 1.8, 1.9 More

Multiple Security Holes In Ruby 1.8, 1.9

Comments Filter:

  • Derailed (Score:2, Funny)

    by lemur3 ( 997863 )
    I can see the blood now!

  • Goes to show ... (Score:2, Insightful)

    by Qbertino ( 265505 )

    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: (Score:3, Insightful)

      by Etherized ( 1038092 )

      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 k

      • Re: (Score:3, Informative)

        by bcrowell ( 177657 )

        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 hav

        • ``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

      • You can also use a still more mature language such as Tcl [www.tcl.tk]. Tcl has to my knowledge had next to no security vulnerabilities in recent years and has a very high quality codebase.

    • Re:Goes to show ... (Score:4, Insightful)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Monday June 23, 2008 @12:42PM (#23905149) Journal

      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.

    • 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!

  • good news (Score:5, Funny)

    by corbettw ( 214229 ) on Monday June 23, 2008 @09:17AM (#23902303) Journal

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

  • Someone had to say... (Score:5, Funny)

    by Hognoxious ( 631665 ) on Monday June 23, 2008 @09:42AM (#23902625) Homepage Journal
    Ruby - it's the new PHP.

  • FUD? (Score:3, Insightful)

    by MarkusQ ( 450076 ) on Monday June 23, 2008 @10:19AM (#23903105) Journal

    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

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

      • 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?

        • 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 va

          • 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

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

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

      • 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

      • 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 o

  • I have patched all of my customer's servers (Score:3, Insightful)

    by MarkWatson ( 189759 ) on Monday June 23, 2008 @10:59AM (#23903599) Homepage

    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" :-)

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

      • 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

        • 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 anymo

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

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

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

            • > 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'r

              • 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

                • > 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 anythin

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

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

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close