Multiple Ruby security vulnerabilities
Posted by Jeremy Kemper June 21, 2008 @ 01:57 AM
Drew Yao at Apple uncovered a handful of nasty security vulnerabilities affecting all current versions of Ruby. The details are still under wraps because an attacker can DoS you or possibly execute arbitrary code—holy crap! Better upgrade sooner than later.
According to the official Ruby security advisory, the vulnerable Rubies are:- 1.8.4 and earlier
- 1.8.5-p230 and earlier
- 1.8.6-p229 and earlier
- 1.8.7-p21 and earlier
Those of us running Ruby 1.8.4 or earlier must upgrade to 1.8.5 or later for a fix. Those on 1.8.5-7 can grab the latest patchlevel release for a fix.
(Please note: Ruby 1.8.7 breaks backward compatibility and is only compatible with Rails 2.1 and later, so don’t go overboard!)
Getting strange errors upgrading from 1.8.6p110 to 1.8.6p230
‘wrong argument type FalseClass (expected Proc)’
for random bits of code after upgrading. Anyone know what’s going on? Google ain’t helping.
There are multiple people having problems with the upgrade from (in our case, 186-p114) to 186-p230.
The error we are seeing is:
method `respond_to?’ called on terminated object (0×7fffffefcf40)
in:
(eval):2:in `protect_against_forgery?’ vendor/rails/actionpack/lib/action_view/helpers/form_tag_helper.rb:404:in `extra_tags_for_form’
I had segfaults on 1.8.6-p230 also. Hopefully we’ll see another release very soon. :(
Dumb question: how can I tell which patch-level I have installed? ruby -v just says 1.8.5
Is there any way to patch on Win32 without having MSVB?
If ruby—version doesn’t work you can in principle determine your patchlevel with ruby -e ‘puts(RUBY_PATCHLEVEL)’ but this didn’t work for me either on one machine running 1.8.4. It seems to do the trick for me on 1.8.5 and 1.8.6.
Thorsten, if you’re on OS X, wait for Software Update patch, if you’re on Linux and installed your ruby from packages, wait for an update. If you’ve built it from source, you sure need to DL new version and rebuild ruby, but, ATM, people are getting segfaults.
I’m getting segfaults on 1.8.5-p231 as well.
Segfaults on both 1.8.5-p231 and 1.8.6-p230. So I’m stuck between a serious security vulnerability and a patched version that brings my site down within two requests. Wonderful!
Eeek! Ruby 1.8.6 p230 won’t let me run script/server! It’s giving a weird C error warning against possible data corruption:
Should i wait for another patch?
This means the clean 1.8.5 version is ok ?
ruby -v gives me: ruby 1.8.5 (2006-08-25)
If you’re not one of those that feel vulnerabilities need to be kept secret, have a look at Zed’s look at the changes made in these latest versions.
Eivind, Zed actually performed lots of non-needed work, comparing the snapshots, while there is a nice svn and git log of all the changes, much better documenting why changes were made and what has been changed.
There is no conspiracy here, and nothing is really was hidden. Everything is in the public repositories.
The version with fixed vulns is available in FreeBSD ports repo. You can try that if you’re a FreeBSD user.
It would be very nice if Rails-core would have verified that the p230 actually works before saying “everyone upgrade”.
I just wasted two hours of my time on this nonsense.
Until there’s a proven exploit on a non-broken web application, I don’t think these should be blown out of proportion.
If your web application is halfway sane, the string and array overflow vulnerabilities should definitely not be a problem. If you deal with strings that are gigabytes in size or arrays with a billion elements; your application is already seriously broken and you’re vulnerable to a DoS anyways (or hardware manufacturers really love you).
Mongrel already has hardcoded limits on all user input except uploaded file sizes; so unless you’re slurping an entire uploaded file into memory, arbitrary user input won’t kill you unless your app does something stupid with it.
Iconv length check: only vulnerable if you’re converting part of a string with iconv.iconv… nobody actually uses that feature; do they?
Unsafe alloca() with sprintf/%: as far as I know (and I could be wrong here), it’s not a problem with gcc; if it works for you now, this should always work unless you’re doing something stupid like passing a ridiculous number of arguments to format a string with.
NULLs in filenames? Not sure why it’s a problem, POSIX file systems don’t allow NULL in pathnames anyways. And for truncated path names, either your application can open a file or it can’t. Shouldn’t be a problem if your file system has a proper permissions system; but maybe I’m missing something. (And I really don’t care for broken filesystems on Win32 or OSX).
rb_str_cat() buffer overrun fixed in r16400 actually seems most interesting and likely to be a problem, and that was fixed well over a month ago. But maybe some malloc implementations compensate for common programmer errors like this and overallocate extra bytes and that’s why we haven’t seen Ruby crashing left and right.
About the NULL in Filenames:
mitsuhiko@nausicaa:/tmp$ echo “Hello World” > myfile.txt mitsuhiko@nausicaa:/tmp$ irb irb(main):001:0> File.new(“myfile.txt\x00” + ”.html”).read => “Hello World\n”
Opening a file in that way is unexpected behavior and a bug, yes; but I don’t see how it’s a vulnerability.
It’s not a path traversal issue; and File.exist?/File.stat already protect you from NULL bytes if you’re checking to see if you’ll clobber an existing file.
Eric: You may want to retract that suggestion. You do not need to handle strings that are billions of bytes long to trip some of these vulnerabilities. People should patch as soon as is feasible.
The worst of these are in Array and String; they can coerce your Ruby interpreter to overwrite native memory at locations of an attackers choosing, if attackers control either the size of an object or the indices used to access them. You should probably assume attackers can do this, since most Ruby (and Python) code relies on exceptions and “nil” returns to catch these conditions.
The “website design” comment copies a comment I made on Reddit, verbatim. Thanks, website design!
Eric:
“foo” and “foo\000” are the same filename as far as open(2) is concern, because open(2) is an ASCIIZ interface. But they aren’t the same Ruby string. If you implement access control based on filenames, and you don’t sanitize the names, you could have a problem.
... but then yeah, not sure why it helps to truncate the string. Never mind, thinking out loud.
So for the Array and String overflow bugs, it would only affect applications that were trivially DoS-able anyways (unless they run on machines with enormous amounts of RAM and sysadmins who don’t care). Basically applications that do stupid things like this:
i = params[:index].to_i # params hash being untrusted user input return array[i] ? "found" : "not found"Patched Ruby or not (or even Perl), the above code is easily DoS-able. If attackers can control memory usage of an application like this, that app is already broken and whoever wrote it needs a serious LARTing.
I’m not saying there’s not a problem in the changes that affect sane apps, but all the CVEs are still being under review and several days have gone by now with no exploits being published to my knowledge.
Perhaps the focus has being on Array and String overflows is misdirection and there’s something else fixed we’re not paying enough attention to… tinfoil hat
Gah, I suck at HTML, missing newline between “input” and “return”
i = params[:index].to_i # params hash being untrusted user input<br /> return array[i] ? "found" : "not found"But yeah, code like this should get people shot :)
OK, self-LART, posting on this blog is challenging because I’m an old fogey with large fonts causing horrible wrapping and my original post actually looks formatted right with regular font sizes :)
“But yeah, code like this should get people shot :)”
Why not educate them instead? ;)
same issue with segmentation fault… doh!
anyone knows if there another patchlevel for fix that comming?
array[params[:index].to_i] isn’t a trivial DoS, Eric. In Ruby, the language Rails is written in, that simply returns “nil”.
My staging box shows no segfaults with ruby 1.8.7 (2008-06-20 patchlevel 22) and Rails 2.1 (knock on wood)
Is the advice to go to Ruby 1.8.7 and Rails 2.1? Well, i am already on Rails 2.1 but having no luck whatsoever with Ruby 1.8.6 patch 230.
OK, nevermind, merely checking
array[params[:index].to_i]is perfectly safe regardless of patchlevel, however assigning witharray[params[:index].to_i] = "foo"is braindamaged and brokenThis is a Ruby bug, not a Rails bug, so I propose that we discuss it over on ruby-talk. Here’s the post: http://www.ruby-forum.com/topic/157034
Here’s a copy of my post from that thread regarding this topic:
All versions of MRI Ruby that claim to fix the vulnerabilities are either failing with segmentation faults or change the API in ways that make it impossible to run vital libraries such as Rails 2.0.x and RSpec. These broken versions include: 1.8.5p231, 1.8.6p230, 1.8.7p22, and 1.9.0-2. Unfortunately, the source code describing some of the proposed fixes has been publicly available now for four days for crackers to write their attacks, so we’re in a race with the bad guys to deliver a solution.
Is anyone working on fixing these bugs? If not, can we rally the community to get a bounty and/or code sprint going?
Is there a way to convince the Ruby maintainers to run new code against the publicly-available test suites provided by RubySpec, Rails and Rspec before they ship a new version to avoid these problems in the future?
Is there anything else that those of us which lack the necessary C expertise to fix these problems can do to help with this effort?
Thank you.
-igal
Count up another guy who’s having trouble with Ruby 1.8.6-p230, in my case on Debian Etch. I’m getting a segfault on “rake test:units”, and a fatal complaint about a double-free from glibc on “rake test:functionals”. My app is not on 2.1 yet, so 1.8.7 is not an option; any reports of success for anyone on 1.8.6-230?
Yet another person running Ruby-1.8.6-p230 on OS X and having problems. Hopefully this gets fixed quickly. Security leaks are bad but so are non-running applications!
Another voice to the masses, 1.8.6-p230 segfaults on my staging server when firing the first request through to mongrel.
Rails 2.1 causes the Proc issue to:
wrong argument type FalseClass (expected Proc) if you do a form_remote_tag() do
Hello Robert, comment 33, i am also on Debian Etch and having the glibc double-free error.
When i did a brand new Rails 2.1 scaffold i still had the segfault error. I think the only answer is to try 1.8.7.
“The details are still under wraps”
Oh, good old security through obscurity again. That makes me feel much safer.
Phusion has backported the security patches to 1.8.6-p111 and made a Ruby Enterprise Edition release based on that. This version is compatible with all your apps. See http://blog.phusion.nl/?p=35 for details.
... and, to clarify, 1.8.7 is only an answer for people who can use Rails 2.1.
It’s probably going to be a while until the Windows builds out there catch up to the “safe” versions, so I decided to try and build 1.8.7-p22 from scratch, with VC8 (VS2005).
In that regard, if anyone else has even tried this yet, have you had problems with the zlib extension when building 1.8.7 from source on Windows? Ruby itself builds without incident (though a bunch of its tests fail; then again, make test-all has a few failing tests on my Mac too)... but zlib segfaults whenever I try to do anything useful, e.g. gem install rails. Not sure if I’ve built zlib wrong (tried binaries and building from scratch, same problem)... wondering if someone dorked the zlib.so extension.
FYI, 1.8.7-p22 and Rails 2.1.0 seem to run without any problems on Mac OS X.
In case anyone is interested, I’ve created some Debian packages (1.8.6p114) with the fixes in. These packages have no problem running older versions of Rails. There is also a simple step-by-step guide available, in case you want to build the packages yourself.
http://www.zaypay.com/public/en/docs/blog
FYI: these bugs are the same or closely related to issues I disclosed to ruby-core years ago. Ruby-core did not take them seriously and did not fix any of the issues. Only now that there is a large user base from the rails side does anyone in the ruby camp seem to care.
Anybody running meaningful applications on rails, merb, etc. should seriously hold the ruby-core community responsible for not having a decent process in place for remediating security issues. Again, it has been known for years that the fundamental constructs used of memory allocation by String and Array (and everything else) are vulnerable to integer overflows and in general there is no sanity checking around stack allocations (alloca) in the ruby 1.8.X code.
Here’s a patch against 1.8.6-p230 which seems to get “rake test” on my app to pass with no complaints:
http://dev.smartleaf.com/misc/p230_fixit_patch.txt
This undoes changeset 17222 on the ruby_1_8_6 branch of the official svn repository (give or take the change to RUBY_PATCHLEVEL). At first blush, at least, the intended change doesn’t look security-related. If there’s anyone here who’d like to try this out, I’d appreciate it (as, perhaps, would other folks…)
So, er, what the hell are we supposed to do about this alert? I have a site in production, I have no idea if it’s really vulnerable since the problem isn’t spelled out, and when I upgrade to the recommended version, Rails barfs. I don’t really feel very good about running somebody’s home brew version of ruby on my production servers. Halp!
Well, most of the “homebrew” versions that are flying around are selections of patches from the official repository. Maurice above and the phusion guys are each trying to select only recent patches relevant to the announced vulnerabilities (though the phusion guys add their own storage-management patches, I believe), while my patch starts with p230 and undoes one particular change which seems to be at the root of the trouble.
If you’re looking for the one closest to some official release, it’s probably what you get by taking “official” p230 and applying my patch (which is, itself, pretty much the output of “svn diff”; it restores class.c to its pre-17222 state and adds no new code.) On the other hand, that also means that you’ve still got all the other new stuff that the ruby core team tossed in, which was apparently less than perfectly tested.
There’s no perfect option here, but I hope that helps.
Any chance the Windows one-click installer can be upgraded to 1.8.7?
Seems as if there is no current ruby version available for win32, which matches the given patch-level, no matter if you would take 1.8.5, 1.8.6 or 1.8.7.
One reason more, to have a deeper look at jruby and tomcat on windows. Does somebody use this combination for production (on windows).
I just upgraded and tested in irb that the path works. I am running 2.0.2 rails. I can confirm that Actionpack seems to have a seg fault… RAILSROOT/vendor/rails/actionpack/lib/action_view/helpers/form_tag_helper.rb:404: [BUG] Segmentation fault ruby 1.8.6 (2008-06-20) [i686-linux]
For those on 1.8.6 you may want to consider downgrading to 1.8.5 until this is worked out.
Errrmmm… people are also apparently having problems with the “security-patched” version of 1.8.5.
Noun
clusterfuck (plural clusterfucks)
(vulgar) A chaotic mess similar to group rape. Its more precise usage describes a particular kind of Catch-22, in which multiple complicated problems mutually interfere with each other’s solution. The looser usage, referring to any chaotic situation, probably prevails.
After upgrading to ruby 1.8.6 (2008-06-20) with Rails 2.1, I got this error trying to load a page in my development environment served with WEBrick:
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/introspection.rb:60: [BUG] Segmentation fault ruby 1.8.6 (2008-06-20) [i386-linux]
Solution: gem update activesupport
This is quite distressing. It has been days, and nothing from Ruby core.
I cannot believe the lack of response on this. It is extremely dismaying.
What I’d expect from a platform that was supported in a serious fashion: an official release of Ruby that works with an official release of Rails that isn’t vulnerable, or a statement that the vulnerability isn’t anything to worry about.
Just adding another voice; I’m experiencing the same seg-fault issues.
/usr/local/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_view/helpers/form_tag_helper.rb:431: [BUG] Segmentation fault ruby 1.8.6 (2008-06-20) [i686-linux]
Robin & Mogden,
I completely agree with you and to be honest, I’m pretty shocked. It would seem this isn’t a high priority with anyone. I think this is going to have a serious negative impact on the Ruby and the Rails community. It’s really an unacceptable situation.
My site was built on rails. Maybe this is why I got hacked? I managed to retrieve my homepage but all the subpages and videos are gone :(
For people hitting segfaults and other ruby weirdness, here’s the patch created by hongli lai that you can apply to ruby version 1.8.6 p11x:
http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt
includes changes to: array.c, bignum.c, eval.c, intern.h, io.c, sprintf.c and string.c
it barfs on webrick, but who runs that in production anyway…
thanks to zed for the heads up on the mongrel list (tho he doesn’t vouch for the patch).
There are now fixed ruby1.8 packages in Ubuntu, which appear to be working ok. Note that these are the old releases with the array/string patches backported.
Yes. I can confirm with Mike on #60. Running fine after Ubuntu update release for Ruby1.8
It barfs in Mongrel too. :(
I installed the Smartleaf p230 patch above and I can confirm that my Ruby app is running fine in production without any segfaults.
If you want to stay on top of the vunerabilities, and are running 1.8.6, this seems to be the way to go.
I am running Fedora 9 and having the same segmentation fault. How do I patch ruby in my case?
Does anybody know if there is an rpm upgrade for ruby?
Disregard what I said above about the smartleaf patch :(... After running for a while the memory usage of all my ruby processes climbed through the room. There are definitely memory leaks present.
I upgrade to ruby-1.8.6_p230 on slackware for production. Thank god everything seems fine with fcgi + apache at server side. but segfault if I try to run with webrick and mongrels. For time being i just downgrade back to ruby-p114 on my pc. :)
PROTIP: This is one of the reasons why people use Enterprisey™ languages/stacks over Ruby/Rails
I tried some of the above but couldn’t get 1.8.6/Rails 2.0.2 working on 64-bit FC8. So I bit the bullet and upgraded to Rails 2.1, but needed this sequence: - build Ruby 1.8.7-p22 from source - install RubyGems 1.2.0 - gem install rails - gem install mongrel - gem install mongrel_cluster
I am having the same segfaults problems after updated to ruby 1.8.6 p230. Webrick and mongrel crash. Phusion passeger works fine. Can anyone suggest a solution to the problem? i am using fedora 8 as operating system.
As far as I can tell, none of these versions/patches (except 1.9) are fully resolving the string aspect of this issue: ruby -v ruby 1.8.6 (2008-06-20 patchlevel 230)
irb(main):001:0> s = “A” * (2**16); nil => nil irb(main):002:0> while 1; s << s; puts s.size; end 131072 (irb):2: [BUG] Segmentation fault ruby 1.8.6 (2008-06-20) [i686-linux]
Aborted
For those on Windows: http://mikehodgson.com/archives/2008/6/30/updated_unofficial_ruby_oneclick_installer
Updates Ruby to 1.8.6p114 with the patches from the Phusion guys.
It’s been a freaking week, and we STILL DON’T HAVE A VIABLE FIX!!
Maybe Zed was right—Rails is a Ghetto!
This is craptacular quality control, and we Developers are expected to build enterprise solutions on top of a broken stack?!
Hey angry gecko – check out this solution and test and let us all know your results (and yes it’s 8 days old)
Patching Ruby 1.8.6 p11X To Avoid SEGFAULTs http://rubyforge.org/pipermail/mongrel-users/2008-June/005449.html
adam.
@Robin Ward – Re: memory leaks in p230
The memory leak is probably not caused by the patch, but by the Ruby code added between p114 and p230. That new code will likely be the basis of the next official release, so it’d be best to identify the problem ASAP.
Another user in ruby-talk is reporting a memory leak in their p230, but isn’t sure how to reproduce it. If you or anyone else can provide code for reproducing the leak, please get in touch at ruby-talk or its online front end at http://www.ruby-forum.com/topic/157034#697304
Thanks!
nouetp: I don’t see that issue with the patched Ruby 1.8.6 in Ubuntu:
irb> s = “A” * (2**16); nil => nil
irb> while 1; s << s; puts s.size; end
131072 ... 1073741824
ArgumentError: string sizes too big from (irb):4:in `<<’ from (irb):4 from :0
WARNING: Do not use Ruby 1.8.6 releases p230 through p238 in production! There are bugs in the Ruby interpreter that cause it to leak memory. Please use a Ruby release that’s based on a patched version of the p111 or p114 code until this is resolved.
I’ve put together code which demonstrates this at: http://pastie.org/226715
From: http://weblog.rubyonrails.org/ (This Week in Rails (June 26, 2008))
“As previously reported by Jeremy Kemper, serious vulnerabilities have been discovered for the main Ruby implementations. The official advisory suggests an upgrade path, but there have been several reports of segmentation faults when using Rails with the patched Ruby 1.8.5 and 1.8.6 versions. The Phusion team has published a patch for Ruby 1.8.6-p111, but as things stand now, it hasn’t been included by the Ruby core team (yet).”
When is the patch going to be included by Ruby core team. Will there be an OFFICIAL PATCH?
I’m using Ruby 1.8.4 (Rails version 1.2.2). My application is running on Linux (under Apache2). I’d really appreciate simple instruction to upgrade to the version with the fix.
I’m looking for the path of least resistance.
May i know what p230 stands for In 186-p230??