Undefined Symbol: Sslv2_Method When Running Bundle Install

undefined symbol: SSLv2_method when running bundle install

I did the following and it fixed the issue:

$ source ~/.rvm/scripts/rvm
$ rvm pkg install zlib
$ rvm pkg install openssl
$ sudo apt-get install libreadline-dev
$ rvm pkg install readline
$ rvm install 1.9.3 --with-openssl-dir=$rvm_path/usr
$ gem install rails

undefined symbol: SSLv2_method when trying to run Thin webserver

As you say, Ubuntu builds openssl without SSLv2 support: Ubuntu and undefined symbol for SSLv2_method

For people reading this, your options are (in increasing difficulty):

(1) install rvm version 1.14.7, where the openssl pkg includes openssl version 0.9.8, and includes SSLv2 support by default.

rvm implode # Completely destroy your rvm installation
curl -L https://get.rvm.io | bash -s -- --version 1.14.7

Install the required packages, recompile your ruby, and it should work!

(2) (This gives you more security): Compile your own openssl from source, configuring it to include SSLv2 support, then recompile your ruby with the --with-openssl-dir pointing at wherever you installed openssl to.

(3) Fix thin so that it no longer requires the SSLv2_method symbol, then submit a pull request on GitHub

Building ruby with rbenv and ruby-build fails with undefined symbol: SSLv2_method

When I run rbenv install 2.2.4 or rbenv install 2.3.0 in both cases the build fails with the error message "undefined symbol: SSLv2_method"...

What could cause these issues ...

The SSLv2 gear was completely removed from OpenSSL in March due to CVE-2016-0800 (DROWN Attack).

I think the complete removal was a bit harsh because of the effects like you are experiencing. There should have been a warning and transition period. And it should have occurred 10 years ago or so.

Instead of complete removal due to DROWN, I think SSLv2_method, SSLv2_client_method and SSLv2_server_method should have set an appropriate error code like ERR_R_REMOVED_INSECURE and returned NULL. <openssl/opensslconf.h> should have unconditionally set OPENSSL_NO_SSL2 also.

OpenSSL realized they broke ABI compatibility and added the symbols back to 1.0.2 with Commit 133138569f37d149. The check-in provided the symbols SSLv2_method, SSLv2_client_method and SSLv2_server_method again, but they return NULL without setting an error code. They also do not define OPENSSL_NO_SSL2. Also see [openssl.org #4398] BUG / 1.0.2g breaks CURL extension.

SSLv2 has been insecure for 15 or 20 years. Packages like Ruby should not have been referencing the symbols. You should file a security bug report against Ruby for referencing the symbol.

---

... and how could I resolve them?

To fix the issue, I believe you need either (1) wait for OpenSSL 1.0.2h, (2), manually patch OpenSSL 1.0.2g, or (3) remove all Ruby references to SSLv2_method, SSLv2_client_method and SSLv2_server_method.

Here's the patch you need for (2), manually patch OpenSSL 1.0.2g:

diff --git a/ssl/s2_meth.c b/ssl/s2_meth.c
index b312f17..d46e2f5 100644
--- a/ssl/s2_meth.c
+++ b/ssl/s2_meth.c
@@ -74,8 +74,8 @@ IMPLEMENT_ssl2_meth_func(SSLv2_method,
                          ssl2_accept, ssl2_connect, ssl2_get_method)
 #else                           /* !OPENSSL_NO_SSL2 */

-# if PEDANTIC
-static void *dummy = &dummy;
-# endif
+SSL_METHOD *SSLv2_method(void) { return NULL; }
+SSL_METHOD *SSLv2_client_method(void) { return NULL; }
+SSL_METHOD *SSLv2_server_method(void) { return NULL; }

 #endif 

You should also configure and compile OpenSSL with at least no-ssl2 no-ssl3 no-comp flags because they are known security problems. The configure options define OPENSSL_NO_SSL2, OPENSSL_NO_SSL3 and OPENSSL_NO_COMP in <openssl/opensslconf.h>.

Ubuntu and undefined symbol for SSLv2_method

The Ubuntu people build OpenSSL without SSLv2 support because the protocol has known security issues. So that's why you can't find SSLv2_method in their library even though you can find it when you compile the library yourself.

Ubuntu build logs are publicly available. You can see in the oneiric-i386.openssl_1.0.0e log that the library gets configured with the -no-ssl2 option, which disables support for SSLv2.

./Configure --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/i386-linux-gnu no-idea no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 debian-i386
Configuring for debian-i386
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-idea         [option]   OPENSSL_NO_IDEA (skip dir)
    no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-mdc2         [option]   OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [option]   OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-shared       [default] 
    no-ssl2         [option]   OPENSSL_NO_SSL2 (skip dir)
    no-store        [experimental] OPENSSL_NO_STORE (skip dir)
    no-zlib-dynamic [default] 

Note that the availability of SSLv23_method does not mean that a client will be able to connect to a server with SSLv2. The OpenSSL documentation briefly discusses this situation:

The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.

What's the point of the --without option in bundle install?

It does seem like a cleanliness issue only, but it is a performance issue, and potentially an overhead issue, as I will explain:

• Cleanliness you covered, less gems in the filesystem. Less network traffic usage ( which might be costly for some, who knows ).

• Performance involves reducing the time it takes to bundle and deploy your application. Saving a few milliseconds or seconds can sometimes matter in a production environment.

• Overhead is the least likely reason. Bundler will only require gems from the :default group automatically, unless you specify other groups in your Bundler.require statement.

Performance more than Cleanliness or Overhead seems to be the best reason for --without

---

Using the --without parameter is also "remembered" by Bundler, so be mindful of that. It's designed to be "set and forget" on the destination environment.

Reference: http://bundler.io/v1.9/groups.html

Bundle install runs from incorrect directory

Sounds like your app is already using bundler and you have a bundler-inside-bundler problem. Try this:

Bundler.with_clean_env do
  puts `bundle install`
end

I'm guessing what's happening is that your outer bundler sets the BUNDLE_GEMFILE env variable to your app's Gemfile, and then your inner bundler ends up inheriting it.

---

Related Topics