-2

I have a Nagios (dev) server built on AWS EC2. The server had preinstalled:

  • OpenSSL 1.0.1k-fips
  • Apache/2.4.25

Qualys scan notified that there are vulnerabilities. The package available on AWS repository points to OpenSSL 1.0.1k-fips, which is the latest so backporting fixes to latest version is out of question, since it was already at the most updated version provided by the vendor. Due to vulnerabilities threat, I had Openssl updated from source to latest version. It now has:

[root@ip-172-31-1-222 ~]# openssl version -a
OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
platform: linux-x86_64
compiler: gcc -DZLIB -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/openssl\"" -DENGINESDIR="\"/usr/local/usr/lib64/openssl/engines-1.1\""
OPENSSLDIR: "/usr/local/openssl"
ENGINESDIR: "/usr/local/usr/lib64/openssl/engines-1.1"

[root@ip-172-31-1-222 ~]# ldd /usr/local/bin/openssl
linux-vdso.so.1 =>  (0x00007ffe24cb3000)
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f94d3a6c000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f94d35e7000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f94d33e2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f94d31c6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f94d2e02000)
/lib64/ld-linux-x86-64.so.2 (0x0000564c46955000)

It still hosts the old version of OpenSSL:

[root@ip-172-31-1-222 ~]# ldd openssl
linux-vdso.so.1 =>  (0x00007ffe5657d000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f41198d1000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f4119683000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f411939b000)
libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f4119198000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f4118f66000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f4118b7d000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4118979000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4118763000)
libc.so.6 => /lib64/libc.so.6 (0x00007f411839e000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f411818f000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f4117f8c000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4117d71000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4117b55000)
/lib64/ld-linux-x86-64.so.2 (0x000055b36b640000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f4117933000)

There are no means to remove the old version. I tried yum remove, it does not work. When I tried to check the mod_ssl & httpd, below output comes:

[root@ip-172-31-1-222 ~]# ldd $(which httpd)
linux-vdso.so.1 =>  (0x00007ffef1511000)
libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fc6e522c000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007fc6e500b000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007fc6e4de5000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc6e4bae000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc6e4985000)
libdb-4.7.so => /lib64/libdb-4.7.so (0x00007fc6e4615000)
libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007fc6e43e2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc6e41c6000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc6e3fc1000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc6e3bfd000)
/lib64/ld-linux-x86-64.so.2 (0x0000564690396000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc6e39f9000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fc6e37f6000)

[root@ip-172-31-1-222 ~]# ldd /etc/httpd/modules/mod_ssl.so
linux-vdso.so.1 =>  (0x00007fffc56fb000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f44e49d6000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f44e45ee000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f44e43d1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f44e41cd000)
libc.so.6 => /lib64/libc.so.6 (0x00007f44e3e09000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f44e3bba000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f44e38d3000)
libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f44e36d0000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f44e349d000)
libz.so.1 => /lib64/libz.so.1 (0x00007f44e3287000)
/lib64/ld-linux-x86-64.so.2 (0x000055f1c2490000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f44e3078000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f44e2e74000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f44e2c5a000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f44e2a38000)

The mod_ssl is not pointing to the new openssl libraries (lib_ssl and lib_crypto), it is poiting to the old version of openssl. I have read somewhere, I need to recompile Apache with mod_ssl from source to make it point to the correct libraries.
The httpd package was updated using yum.

[root@ip-172-31-1-222 ~]# httpd -V
Server version: Apache/2.4.27 (Amazon)
Server built:   Aug  2 2017 18:02:45
Server's Module Magic Number: 20120211:68
Server loaded:  APR 1.5.1, APR-UTIL 1.4.1
Compiled using: APR 1.5.1, APR-UTIL 1.4.1
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/run/httpd/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Now, the questions are:

  1. Do I really need to recompile Apache?
  2. Is it not possible to just recompile mod_ssl or perhaps some editing to point to new libraries?

  3. If I have to recompile Apache from source, what parameters I need to choose for ./config, so that it doesn't break my existing setup?

  4. Perhaps, remove httpd using yum and then install it from source?

Note:

  1. I have already backed up all httpd related files/conf from the server
  2. We are using company authentication for nagios

If you need further information, please do let me know.

  • This kind of commentary is not acceptable. Voting is anonymous for a reason and you can assume that the downvote has been cast because This question doesn't show any research effort, is unclear or not useful (this is the mouse-over text of the downvote arrow). – Sven Sep 10 '17 at 11:35
  • What research effort are you asking about? I am not expecting anyone to spoonfeed me the settings. I am unsure whether I need to recompile the entire package or not and that is the reason the question was put in the first place. Regarding the comment, yes I agree it is not acceptable and I take back my words for the same. – Amitabh Ghosh Sep 10 '17 at 12:13
  • I cited the mouse-over text. And yes, I would agree that you are lacking research. Research about the basic operations of the environment you are running in, which would have shown you that there was never any need to recompile OpenSSL to begin with because your OS vendor does that for you. – Sven Sep 10 '17 at 12:20
  • And that is the exact reason why you should had read the last line. I did a qualys scan which showed the vulnerabilities. Regarding backporting, it was already at the most updated version provided by the vendor. The link you provided doesn't help as they point to the same version and yet qualys reports vulnerability – Amitabh Ghosh Sep 10 '17 at 12:26
  • It's your job to explain everything relevant to your question. If you don't, this is entirely on you. – Sven Sep 10 '17 at 12:35
1

If you are on a supported version of any OS, you don't even need to compile OpenSSL, as this is done by the OS vendor. Usually, they backport the fixes in their version, so even versions that are vulnerable in the upstream are usually safe when used from the OS vendor. This is also the case for AWS and Amazon Linux. See https://alas.aws.amazon.com/ to check which CVE numbers are fixed in what package version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.