"gem install" fetches packages from unencrypted HTTP URL

Bug #1467716 reported by Simon Déziel
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ruby1.9.1 (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Running "gem install $FOO" fetches $FOO using unencrypted HTTP which is insecure.

Steps to reproduce:

1. apt-get install ruby
2. echo 'source "https://rubygems.org"' > Gemfile
3. gem install bundler

One would expect this to use HTTPS to download but it's not the case.

Additional information:

# lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04

# apt-cache policy ruby
ruby:
  Installed: 1:1.9.3.4
  Candidate: 1:1.9.3.4
  Version table:
 *** 1:1.9.3.4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Simon Déziel (sdeziel)
information type: Private Security → Public Security
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I know that years ago "gem install" was horribly insecure, but I believe this has been improved upstream? So is this a bug in Ubuntu's packaging, or is it that it is fixed in a newer upstream (and/or Ubuntu) release, or is what you're reporting still a problem upstream?

I'll also note that using unencrypted HTTP isn't necessarily "insecure". Cryptographic verification can be done using digital signatures outside the transport protocol (for example apt does this), which is arguably more secure because it protects data at rest as well as in transit. For example, even if an apt mirror is compromised the signatures and thus package contents cannot be since the apt repository private signing keys aren't held on any mirror.

Finally, HTTPS doesn't necessarily protect privacy for software repositories either, as any attacker who could compromise your HTTP download can also observe the size and timing of your HTTPS downloads and thus often be able to guess what packages you downloaded from a repository that is already public.

So it would be useful if you could please clarify exactly what you mean by "insecure", and what needs to be fixed in Ubuntu as opposed to what is available in a newer release and what needs fixing upstream.

Revision history for this message
Simon Déziel (sdeziel) wrote : Re: [Bug 1467716] Re: "gem install" fetches packages from unencrypted HTTP URL

On 06/23/2015 05:36 AM, Robie Basak wrote:
> I know that years ago "gem install" was horribly insecure, but I believe
> this has been improved upstream? So is this a bug in Ubuntu's packaging,
> or is it that it is fixed in a newer upstream (and/or Ubuntu) release,
> or is what you're reporting still a problem upstream?

I'm unsure about where the problem originate. I've only tested this on
Ubuntu Trusty.

> I'll also note that using unencrypted HTTP isn't necessarily "insecure".
> Cryptographic verification can be done using digital signatures outside
> the transport protocol (for example apt does this), which is arguably
> more secure because it protects data at rest as well as in transit. For
> example, even if an apt mirror is compromised the signatures and thus
> package contents cannot be since the apt repository private signing keys
> aren't held on any mirror.

You are right. In this specific case, the files are not
cryptographically signed as shown when asking for signature validation [1]:

# gem install bundler -P HighSecurity
Fetching: bundler-1.10.5.gem (100%)
ERROR: While executing gem ... (Gem::Exception)
    Unsigned gem

> Finally, HTTPS doesn't necessarily protect privacy for software
> repositories either, as any attacker who could compromise your HTTP
> download can also observe the size and timing of your HTTPS downloads
> and thus often be able to guess what packages you downloaded from a
> repository that is already public.
>
> So it would be useful if you could please clarify exactly what you mean
> by "insecure",

I must admit that saying that HTTP is "insecure" is overly broad. My
main concern was MITM attacks. I agree with you that HTTPS alone isn't a
silver bullet but it would still be an improvement security-wise.

> and what needs to be fixed in Ubuntu as opposed to what
> is available in a newer release and what needs fixing upstream.

Having gem always use the HTTPS URL to rubygems.org would be sufficient
to at least prevent MITM attacks. A quick look at the upstream git tree
showed that they use the HTTPS scheme to reach rubygems.org.

Regards,
Simon

1: http://guides.rubygems.org/security/#using-gems

Revision history for this message
Robie Basak (racb) wrote :

Thank you for your reply. I think this bug needs further investigation in comparing the Ubuntu packaged versions to upstream versions to figure out if and where the gap appears.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

The instructions given in the bug description aren't accurate.

The make gem use an https URL, you need to create an /etc/gemrc or ~/.gemrc file with the following contents:

:sources:
- https://rubygems.org

Make sure it works by using "gem environment" and making sure "REMOTE SOURCES" is using the https URL.

Changed in ruby1.9.1 (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
importance: Wishlist → Low
Revision history for this message
Simon Déziel (sdeziel) wrote :

Indeed, the gemrc way is much cleaner. Thanks

Revision history for this message
Simon Déziel (sdeziel) wrote :

On Bionic, the stock default sources are using HTTPS:

$ gem environment | grep -A1 'REMOTE SOURCES'
  - REMOTE SOURCES:
     - https://rubygems.org/

So it's no longer required to create a /etc/gemrc or ~/.gemrc file.

Changed in ruby1.9.1 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.