Feature #1800: rubygems can replace system executable files

• Status: Closed
• Assignee: drbrain (Eric Hodel)
• Target version: 1.9.4

[znz (Kazuhiro NISHIYAMA)]

=begin
Japanese blog http://wota.jp/ac/?date=20090604#p01 says,
gem has bin/ls and Gem::Specification#executables= ["ls"],
rubygem overwrites /usr/bin/ls without confirming.

I think this is potential security risk.
=end

[raggi (James Tucker)]

=begin
Doing sudo <installer> <package> is always a security risk.

Rubygems is neither the cause nor the vector for such an exploit.

The specific vector requires that the default install location be customised (e.g. Ubuntu / Debian)

Without a system registry, rubygems can at best warn that it will overwrite something, it cannot hold this notion of "system executable files", which is not clearly defined.
=end

[runpaint (Run Paint Run Run)]

=begin

Without a system registry, rubygems can at best warn that it will overwrite something, it cannot hold this > notion of "system executable files", which is not clearly defined.

It really should prompt before overwriting a file it didn't create, though. IOW, it doesn't need to know what a "system executable file" is, just what binaries it has installed for other gems.
=end

[marcandre (Marc-Andre Lafortune)]

• Category set to lib
• Assignee set to drbrain (Eric Hodel)

=begin

=end

[mame (Yusuke Endoh)]

=begin
Hi,

Eric Hodel has a duty to reply the ticket.

IMO, agreed with Run Paint. RubyGems should at least prompt.

--
Yusuke Endoh [e-mail]
=end

[darix (Marcus Rückert)]

=begin
Eric and myself discussed this on irc and came to the conclusion that rubygems would need to track binaries installed by gems with path and their checksum.
When it updates a gem it would only overwrite the binary if the checksum still matches and the binary belongs to a former version of the same package.

the other option would be a seperate bin dir that you have to add to your $PATH.
=end

[mame (Yusuke Endoh)]

=begin
Hi,

2010/3/20 Marcus Ruckert [e-mail]:

Eric and myself discussed this on irc and came to the conclusion that rubygems would need to track binaries installed by gems with path and their checksum.
When it updates a gem it would only overwrite the binary if the checksum still matches and the binary belongs to a former version of the same package.

Thank you for replying! I think the feature is good.

Let us know what's the current status. Has it been implemented? Will
it be included in 1.9.2?

If it seems impossible, I'll change the target of this ticket to 1.9.x.

Thanks,

--
Yusuke ENDOH [e-mail]

=end

[sakuro (Sakuro OZAWA)]

=begin
Marcus, by this idea, what happens when a gem is being newly installed, not updated and there is a file that the gem is to overwrite?
I think we cannot track gem's wrappers' checksums since the sh-bang line may differ envs to envs in this case.

=end

[mame (Yusuke Endoh)]

• Priority changed from Normal to 5
• Target version set to 1.9.2
• ruby -v set to ruby 1.9.2dev

=begin
Hi,

I guess this feature request includes solution for security concern.
So I moved it to Bug tracker. Tell me if the move has a problem.

--
Yusuke Endoh [e-mail]
=end

[mame (Yusuke Endoh)]

• Priority changed from 5 to 6

=begin
Hi, Eric

What do you think about this issue?
Are you planning to fix this before 1.9.2 release?

--
Yusuke Endoh [e-mail]
=end

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Priority changed from 6 to Normal
• Target version changed from 1.9.2 to 2.0.0

=begin
Hi,

I realized more serious concern; "sudo gem install" executes
extconf.rb with root access, which enables code execution by
"an attacker".

I think this does not means any security issue, but means a
simple fact that rubygems assumes a user does not install
untrusted gems.

It is better to have an option to prompt before rewriting a
file or executing extconf.rb.
So I move this ticket to 1.9.x feature.

--
Yusuke Endoh [e-mail]
=end

[luislavena (Luis Lavena)]

=begin
On Sun, Jun 6, 2010 at 9:07 AM, Yusuke Endoh [e-mail] wrote:

I realized more serious concern; "sudo gem install" executes
extconf.rb with root access, which enables code execution by
"an attacker".

I think this does not means any security issue, but means a
simple fact that rubygems assumes a user does not install
untrusted gems.

It is better to have an option to prompt before rewriting a
file or executing extconf.rb.

Please note that any gem update that needs to replace a stub script
(rake, capistrano, etc) will prompt, so sudo gem update will be
pretty annoying.

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[mame (Yusuke Endoh)]

=begin
Hi,

2010/6/6 Luis Lavena [e-mail]:

It is better to have an option to prompt before rewriting a
file or executing extconf.rb.

Please note that any gem update that needs to replace a stub script
(rake, capistrano, etc) will prompt, so sudo gem update will be
pretty annoying.

My opinion is an option to prompt, such as "gem update --prompt", for
conservative people. I'm not insisting to make the option default.

I also agree with the feature Marcus mentioned in [ruby-core:28782].
It would be much better to prompt only when replacing a file that is
not under rubygems' management.

Anyway, this is just my opinion. I don't (can't) force Eric, though
I want Eric to express his own view or status.

--
Yusuke Endoh [e-mail]

=end

[drbrain (Eric Hodel)]

=begin
Adding --prompt as a stopgap that defaults to off is acceptable to me. I don't know if I will have time to implement it until next week, though.
=end

[vbatts (Vincent Batts)]

The --prompt option would leave vague, an important aspect of the implementation though, like gem update and gem uninstall.
It would seem then, let a state of omission should need to be recorded for the gems. So that those executables can be handled accordingly.

If a user were only --prompt'ed on the installation, but later the --prompt is omitted, and gem removes /usr/bin/ls, then it is no less better than clobbering the file in the first place. The user would effectively have to use --prompt on every install, update, pristine and uninstall.

For the same amount of work, to the user typing the flags, a more acceptable solution should be to create an alternate path, for executables to land ("/usr/ruby/bin") and have it in your shell's PATH (export PATH=/usr/ruby/bin:$PATH). Every time you gem install, just add the flag "-n DIR" or "--bindir DIR". This way, at best, a gem will only clobber other gems.

[drbrain (Eric Hodel)]

• Status changed from Assigned to Closed
• Target version changed from 2.0.0 to 1.9.4

I've implemented this in the RubyGems repository, but it is too big a change to go into 1.9.3.

Rather than having users opt-in to checking if a RubyGems executable will overwrite something in their bin dir I'm using the following rules:

If --force was used, overwrite

If the executable exists and is for a different gem the user is consulted

If the executable exists and is in the default bin directory (for example, /usr/local/bin) the user is consulted

Otherwise, the executable is overwritten (gem reinstall or somebody was messing with the repository's bin directory)

With the fake gems of 1.9.x I think this meets all the criteria.

See:

https://github.com/rubygems/rubygems/commit/415c0ec4
https://github.com/rubygems/rubygems/commit/5298fffd