Upgrading / installing OpenSSL 1.0.0d from source on CentOS 5.5

SynKyo · 06-26-2011, 12:34 PM

Hey all,

I find my self abit stuck upgrading OpenSSL to the latest version. The situation is that i've been running LAMP servers just fine by installing the web services from the repositories AND the web services from source. However im now in the process of making a PCI-DSS compliant server LAMP server. I've just had the vulnerability scan report back and its failed due to the OpenSSL having vulnerabilities and it tells me I must upgraded to version higher 1.0.0d.

I've basically spent hours and hours trying to get this working along with research but I dont seem to be having much luck with this one, so any help on the following methods i'm using is much appreciated.

Im using a fresh install of CentOS and trying to create a RPM using the source code and rpmbuild, I read this was the best way I read, and this is my first time using rpmbuild.

Code:

yum -y install rpm-build make gcc gcc-c++ perl mlocate

cd /usr/src/
wget http://www.openssl.org/source/openssl-1.0.0d.tar.gz

updatedb

tar -zxf openssl-1.0.0d.tar.gz openssl.spec

mv /usr/src/openssl-1.0.0d/openssl.spec /usr/src/redhat/SPECS/

cp /usr/src/openssl-1.0.0d.tar.gz /usr/src/redhat/SOURCES/

vi /usr/src/redhat/SPECS/openssl.spec
# I had to change the following due to a legacy error
# CHANGE: Copyright -> License

# I then changed the following because running rpmbuild was telling me into couldnt find the glob'ed files
# CHANGE: %attr(0755,root,root) /usr/lib/*.so* -> %attr(0755,root,root) /usr/lib64/*.so*
# CHANGE: %attr(0644,root,root) /usr/lib/*.a -> %attr(0644,root,root) /usr/lib64/*.a
# CHANGE: %attr(0644,root,root) /usr/lib/pkgconfig/openssl.pc -> %attr(0644,root,root) 

rpmbuild -ba /usr/src/redhat/SPECS/openssl.spec

This gave me the following error

Code:

error: Failed dependencies:
        perl(WWW::Curl::Easy) is needed by openssl-1.0.0d-1.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) fipscheck-1.2.0-1.el5.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) cyrus-sasl-2.1.22-5.el5_4.3.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) wget-1.11.4-2.el5_4.1.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) openldap-2.3.43-12.el5_6.7.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) m2crypto-0.16-7.el5.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) python-libs-2.4.3-44.el5.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) iscsi-initiator-utils-6.2.0.872-6.el5.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) openssh-4.3p2-72.el5_6.3.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) openssh-server-4.3p2-72.el5_6.3.x86_64
        libcrypto.so.6()(64bit) is needed by (installed) openssh-clients-4.3p2-72.el5_6.3.x86_64
        libssl.so.6()(64bit) is needed by (installed) wget-1.11.4-2.el5_4.1.x86_64
        libssl.so.6()(64bit) is needed by (installed) openldap-2.3.43-12.el5_6.7.x86_64
        libssl.so.6()(64bit) is needed by (installed) m2crypto-0.16-7.el5.x86_64
        libssl.so.6()(64bit) is needed by (installed) python-libs-2.4.3-44.el5.x86_64

So I tried:

Code:

rpm -Uvh /usr/src/redhat/RPMS/x86_64/openssl-1.0.0d-1.x86_64.rpm --nodeps

This appeared to work and the version number was correct when I used openssl version

But my problem is now that yum is broken, along with wget and probably anything else that uses OpenSSL.

When I do yum update, I get the following error:

Code:

Traceback (most recent call last):
  File "/usr/bin/yum", line 4, in ?
    import yum
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 51, in ?
    import config
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 27, in ?
    from parser import ConfigPreProcessor
  File "/usr/lib/python2.4/site-packages/yum/parser.py", line 3, in ?
    import urlgrabber
  File "/usr/lib/python2.4/site-packages/urlgrabber/__init__.py", line 53, in ?
    from grabber import urlgrab, urlopen, urlread
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 412, in ?
    import keepalive
  File "/usr/lib/python2.4/site-packages/urlgrabber/keepalive.py", line 339, in ?
    class HTTPSHandler(KeepAliveHandler, urllib2.HTTPSHandler):
AttributeError: 'module' object has no attribute 'HTTPSHandler'

Im really stumped on this one here, so any help at all or any suggestions on better ways to do this whole process is greatly appreciated, thanks in advanced.

Tinkster · 06-26-2011, 12:40 PM

Hi, welcome to LQ!

The better approach would have been to wait for RedHat/Centos to
provide you with an updated version (alternatively take care of
compiling ALL dependent libs and executables yourself, having
marked the new version of SSL in their respective *.specs as
the one they really want to depend on).

Cheers,
Tink

pingu · 06-26-2011, 01:23 PM

My approch is completely different.
If you want your server PCI-compliant you should really think in advance.
You can not wait for Centos (or any distro) to release proper versions, you will need to update faster than that. Believe me, my job is to make sure all of a company's servers are PCI-compliant highest level so I really know what I'm talking about.

My advice to you is to compile all software needed manually, and in non-original directories. Suggestion: create a partition for all this software, mount under /myapps (or whatever you like).
For a LAMP-server that means compiling openssl, mysql, apache (well, webserver of your choice), php and pcre (pcre may not be necessary but it definitely is if you want mod_security which you might not want now but it will make your life easier having it. A little hard to learn but worth the effort. Plan for it - compile pcre, it's very easily done.)

Beware of install-order: Openssl first, then you compile all other programs against that version. This means you do not need to replace systems Openssl which - as you have noticed - breaks pretty much everything.

Second advice is that you make scripts to handle the compiling.
This makes it so much easier when you need to upgrade an application - and upgrades will be necessary pretty often, believ me!
To help you along I attach my script for compiling mysql.

(And just out of curiosity, why do you want PCI? Business reasons or just for the fun of it?)

Good luck, just return if you need more help!

Oh yes, your broken system: try reinstalling original openssl with yum, hopefully it helps.
If it doesn't, maybe you can install same version of Centos on some other 'puter and copy over necessary files (I think they all are under /etc/openssl but not sure, you have to check!)
Last resort is reinstall...

Tinkster · 06-26-2011, 04:05 PM

Quote:

Originally Posted by pingu

My approch is completely different.
If you want your server PCI-compliant you should really think in advance.
You can not wait for Centos (or any distro) to release proper versions, you will need to update faster than that. Believe me, my job is to make sure all of a company's servers are PCI-compliant highest level so I really know what I'm talking about.

I'm curious: how many machines, how many OSes in how many versions,
how many architectures are you looking after?

Cheers,
Tink

SynKyo · 06-26-2011, 04:09 PM

Yes I cant wait for the releases to be updated by CentOS. Once a vulnerability is discovered its essential its fixed asap.

I do currently have all my web services (MySQL, Apache, PHP) compiled from source and up to date as it is, they all work fine. I was getting on fine with compiling OpenSSL from source and then compiling against that, but this didnt change the version number when I did # openssl version, I though this would still be an issue when I do the next vulnerability scan, is this not the case? Will the scan only care about what version of OpenSSL Apache and PHP are using?

My yum is screwed from installing the RPM I built from source, I'm currently doing all this on a cloud environment server anyway, so its not a bother to just reinstall CentOS

Oh and currently its for business reasons. Thanks for your help, i'll go back to just compiling OpenSSL from source and then compiling Apache and PHP along side that if its not going to be an issue using 2 versions of OpenSSL on a system.

SynKyo · 06-27-2011, 02:54 PM

So now im trying to compile apache with mod_ssl and openssl-1.0.0d but I dont seem to be having much luck with that either. All the info I seem to find around is geared towards compiling Apache 1.3.x and when I change it around for to the following

Code:

./configure \
    --with-apache=/usr/local/src/httpd-2.2.19/ \
    --with-ssl=/usr/local/src/openssl-1.0.0d \
    --prefix=/usr/local/apache

I get the following:

Code:

Configuring mod_ssl/2.8.30 for Apache/1.3.39
./configure:Error: Cannot find Apache 1.3 source tree under /usr/local/apache/
./configure:Hint:  Please specify location via --with-apache=DIR

So I then check http://www.modssl.org/source/ and notice the Apache number matches up with the one I've downloaded and I dont see any for Apache/2.x.x, so im now at a loss with what to do now. Any help/guidance at all on this one would go a long way

Tinkster · 06-27-2011, 03:32 PM

Code:

--with-apache=/usr/local/src/httpd-2.2.19/ \  !=  /usr/local/apache/

And I'd go w/ pingu's suggestion; create a new directory
structure that makes sure the "new" versions don't get in
the way of the distro maintained ones.

I built some apps that are newer than RHEL ones and
placed them (w/ their respective OpenSSL) under /opt, without
adding them to the ld.so.conf.

Cheers,
Tink

SynKyo · 06-28-2011, 04:38 PM

I'm now going with the method of placing everything in a separate place.

Everything 'seems' to be going OK apart from OpenSSL still.

Im getting an error of:

Code:

The output of /opt/apache/bin/apxs follows:
/opt/apache/bin/httpd: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

I get this error from compiling PHP using the following:

Code:

./configure --prefix=/opt/php --with-apxs2=/opt/apache/bin/apxs --with-mysql=/opt/mysql --with-mysqli=/opt/mysql/bin/mysql_config --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr --enable-exif --enable-ftp --with-zlib-dir=/opt/zlib --enable-gd-native-ttf --enable-calendar --enable-mbstring --with-curl=/opt/curl --with-mcrypt=/opt/mcrypt --with-openssl=/opt/openssl/ --without-pear

I've checked with locate and libssl is in /opt/openssl/lib.

I'm using the config of

Code:

./config shared --prefix=/opt/openssl --openssldir=/opt/openssl -fPIC

for OpenSSL, I've tried this without -fPIC, I've tried it with and without shared too. I'm also getting the following error too.

Code:

libssl.a relocation R_X86_64_32 against a local symbol can not be used when making a shared object; recompile with "-fPIC"

Again, any help on this one is greatly appreciated

pingu · 06-29-2011, 05:58 AM

I remember this, had the same problem on one server recently.
Thing is, for some reason openssl-1.0.0d has to be compiled with "./config shared", and then the "--prefix" & "--openssldir" are ignored.
One way to fix it is to find where openssl is installed and use that path when configuring apache et al. (In my case (SLES11) openssl was installed in /usr/local/openssl with source in /usr/local/src/)

Another way, and what I did, is after running ./config, edit Makefile and change INSTALLTOP= and OPENSSLDIR= to where you want openssl installed.

And to answer an earlier question:

Quote:

I was getting on fine with compiling OpenSSL from source and then compiling against that, but this didnt change the version number when I did # openssl version, I though this would still be an issue when I do the next vulnerability scan, is this not the case? Will the scan only care about what version of OpenSSL Apache and PHP are using?

Well, for us it didn't matter what "# openssl version" reported - the scanner can't reach the terminal & we have no other services accessible from outside. Of course this might be different on your system.

pingu · 06-29-2011, 06:10 AM

Quote:

Originally Posted by Tinkster

I'm curious: how many machines, how many OSes in how many versions,
how many architectures are you looking after?

Straight answer: 8 servers (although scanner can only access 5), only OpenSuse & SLES.

What I think you're after is: "How can I rule out all distros without actually trying them? Do I really know enough of at least the major 20 distros?"
Answer is simple: If you need PCI then you must have complete control. It doesn't matter what distro / OS you are running, you simply can't just trust their maintainers to release updated version of a package the day after it is released. There can always be a delay, and if you don't get a green scan regularly you lose your certification.
So my conclusion is not based on how fast distro X or distro Y updates their packages, it is based upon the need of control. It is based upon the fact that even if distro is updated fast enough in 99% of the cases, that 1% might cause me to lose PCI certification, which would be a disaster for the company!

Tinkster · 06-29-2011, 12:38 PM

Quote:

Originally Posted by pingu

Straight answer: 8 servers (although scanner can only access 5), only OpenSuse & SLES.

What I think you're after is: "How can I rule out all distros without actually trying them? Do I really know enough of at least the major 20 distros?"

Actually I was just after the practicality of the approach.

Assume you had 800 instances, spread over three hardware platforms and
several versions of the OS that come w/ it.

Assume that 0-day exploit gets noticed while you are asleep.

Just putting it out there.

Cheers,
Tink

SynKyo · 07-01-2011, 07:31 PM

I managed to get this working now! I needed the following:

Code:

echo "/opt/openssl/lib" >> /etc/ld.so.conf
ldconfig

Thanks for the help guys