A system integrity violation flaw was found in the way RubyGems used to handle it's external Gem archives. A remote attacker could provide a specially-crafted Gem (POSIX tar) archive, which once opened by an unsuspecting user would overwrite relevant system file. References: ---------- http://bugs.gentoo.org/show_bug.cgi?id=278566 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/24472 http://redmine.ruby-lang.org/issues/show/1800 Reproducer: ---------- http://bugs.gentoo.org/attachment.cgi?id=198688&action=view Credit: ------ Kazuhiro NISHIYAMA Workaround: ----------- All Fedora RubyGems users are strongly recommended not to install untrusted third-party RubyGems Gem archives.
CVE has been requested here: http://www.openwall.com/lists/oss-security/2009/07/21/3 Note: Please ensure to mention a relevant CVE identifier in the RubyGems changelog while scheduling Fedora / EPEL RubyGems updates / fixing the issue.
According to Gentoo bug report, this got CVE back in 2007 (CVE-2007-0469), but never got properly addressed upstream: http://bugs.gentoo.org/show_bug.cgi?id=278566#c3 Testing gem is also available in Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=278566#c1
There is still no real activity or solution upstream on this issue. Last month some discussion started again after 6mos of silence, but still no fix available.
# gem install testgem-0.0.1.gem Successfully installed testgem-0.0.1 1 gem installed Installing ri documentation for testgem-0.0.1... File not found: lib # ls -al /usr/bin/less -rwxr-xr-x 1 root root 373 Dec 20 15:39 /usr/bin/less # vim /usr/bin/less # less haha, I'm not less! # rpm -q rubygems rubygems-1.3.7-1.fc13.noarch Can we not just change the default_bindir in /usr/lib/ruby/site_ruby/1.8/rubygems/defaults.rb? 68 # The default directory for binaries 69 70 def self.default_bindir 71 if defined? RUBY_FRAMEWORK_VERSION then # mac framework support 72 '/usr/bin' 73 else # generic install 74 ConfigMap[:bindir] 75 end 76 end It seems pretty straightforward to me. Can we make something like /usr/bin/gems/ (or maybe even in /usr/local/bin/?) where this stuff gets installed. Obviously it's still broken.
Created rubygems tracking bugs for this issue Affects: fedora-all [bug 664605]
So is this reproducible as non-root or as root only? If this is as root only, I think this is not a bug because "gem" is considered as rpm, dpkg(?) and so on, and IMO is actually expected to override any files freely.
No, it isn't reproducible as non-root. Unfortunately, it looks like gem installation as non-root may not work either though. The default --install-dir passed (from gem help install) is /usr/lib/ruby/gems/1.8 so trying to install as non-root with no options: % gem install testgem-0.0.1.gem ERROR: While executing gem ... (Gem::FilePermissionError) You don't have write permissions into the /usr/lib/ruby/gems/1.8 directory. So the question then becomes, what does the user do? Do they read manpages and help output to provide the --user-install option, or do they do the quick/easy thing and "sudo gem install [gem]"? I think if you answer that honestly, you'll see why we might have a problem. % gem install testgem-0.0.1.gem --user-install WARNING: You don't have /home/vdanen/.gem/ruby/1.8/bin in your PATH, gem executables will not run. Successfully installed testgem-0.0.1 1 gem installed Installing ri documentation for testgem-0.0.1... File not found: lib This works, but look where it's installing. ~/.gem/ruby/1.8/bin. That's a great place for it and makes sure it will only every clobber itself or other gems. Now, if the default for installing for a user is in a directory such as that (why not clobber stuff in ~/bin/?), why are we allowing gems to be installed in /usr/bin/? They should be put in a similar directory, perhaps /usr/lib/ruby/site_ruby/1.8/bin/ with the same "it's not in your path" warning. I find it odd that for a user-install it will go through some steps to localize/centralize the install, but for a system-wide install it is allowed to clobber arbitrary files. Now, I do understand that gem is like rpm or dpkg or any other packaging system and I completely agree that installing gems as root is bad. But given what the defaults of "gem install" are, I think people will be installing as root. If you don't want to change the default of where gems are installed to, then there are at least two perfectly valid alternatives: 1) warn the user that files will be overwritten _before_ they are overwritten so they can at least CTRL-C out of it 2) make the gem install command have a default of --user-install so you have to explicitly pass --no-user-install to get it installed system-wide
I'm lowering the severity of this flaw to low. This isn't really a serious flaw. If you're install untrested gems, you have far bigger issues than this. I agree that a gem should not be able to overwrite random things in /bin though, so we'll still call it a flaw. It will be in our best interest to follow upstream on this one. Blazing our own path is only going to cause trouble down the road.
Note that there was submitted fix into the upstream repository [1]. Also note that for F17, we are going to install system-wide gems into /usr/local [2], therefore they will not conflict with anything installed by RPM. [1] http://bugs.ruby-lang.org/issues/1800#note-15 [2] https://github.com/voxik/ruby.spec/blob/master/operating_system.rb
Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.