9

I'd like to compile and install a Heartbleed-vulnerable OpenSSL version on a server I'm setting up for a team web security challenge (since these are not available for install from Ubuntu's repository for obvious reasons).

I downloaded and compiled from source OpenSSL 1.0.1f using the provided instructions (run ./config, then make and make install), and tried to run the openly available Heartbleed POC from GitHub from my PC, however the script is notfying me that no heartbeat response has been received and the server is likely not vulnerable.

Running openssl version produces the following output: OpenSSL 1.0.1f 6 Jan 2014. I installed an SSL certificate of course and SSL access works on the server.

OpenSSL is installed to work with Apache 2.4.7.

Can anyone help?

mittelmania
  • 209
  • 2
  • 10
  • 3
    In general, a good way to test older versions and Linux distributions is to download older ISO images of the distribution, and possibly install a VM using it. Not all packages are available in this, but OpenSSL would certainly be. – Bruno Mar 03 '15 at 00:13
  • If you're somewhat familiar with Debian packaging, it should be fairly easy to download your current openssl source package, remove CVE-2014-0160.patch, and rebuild it. – Matt Nordhoff Mar 03 '15 at 00:45

2 Answers2

7

What server software is being used?

Despite the OpenSSL binary being vulnerable, an installed web server from an OS package is likely to be using a library version that is not vulnerable.

The simplest way to get a vulnerable listener running will be openssl s_server - if you need a full web server to be vulnerable, you'll likely need to compile against the vulnerable OpenSSL.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • 1
    Whoa, I never knew `s_server` was a thing. I've been using `s_client` forever, and it makes complete sense that there should be a server option as well. – EEAA Mar 02 '15 at 23:24
  • 1
    @EEAA Yeah, it's crazy how many different subcommands are crammed in there. – Shane Madden Mar 02 '15 at 23:26
7

There are two things that may be going on here:

  1. A simple "./configure; make; make install" will by default place the shared libraries in /usr/local/lib. The system-installed libraries, however, will be in /usr/lib, which comes earlier in the library search path. Unless you remove the system-installed version of OpenSSL, the vulnerable version won't be found.

  2. Even if you are over-writing the system libraries, the change won't be picked up until you restart Apache. Deleted files remain accessible (and take up space on disk) until all programs that have open filehandles to them close those filehandles.

Mark
  • 668
  • 4
  • 10