Vulnerabilities were announced in Ruby during the last week. Details are still limited, but they’re starting to seep out as people start analyzing the patches/source tree. These vulnerabilities, and others like it in Python/Perl/etc are interesting for a lot of reasons but mostly because too many people point to using these languages as a safe alternative to C/C++, just a week or two ago this argument was being pushed by some on a popular SCADA security mailing list. This isn’t the first such problem with an interpreted language, and it certainly won’t be the last, more and more research resources are being put into examining these.
The problem is that these interpreters are still vulnerable to the same sort of problems as well as different sets of problems, and simply swapping over to another language/environment is no remedy for unsafe coding practices, and at times it has the potential to make threats much harder to mitigate and patches more difficult to apply. For example, let’s say a component of your infrastructure is using one of these interpreted languages, when a vulnerability is found not only does the vendor have to release a new version of the interpreter to fix the problem they may also have to update all the scripts that were written for it. Throw proprietary add-on modules and you’ve got a mess and potentially a very long time diff between patches in the main tree and patches to a specific system.
That isn’t to say that interpreted languages don’t have their place, and that their scope hasn’t grown significantly, because they do and have. I’m a big fan of both Python and Ruby, and use them both often, but it’s time to end the argument that these languages and platforms are some great panacea for security problems.