OpenSSL update

I read a lot of messages saying it is now needed to replace the keys, also, since these may have been leaked without any trace of it. Is that needed here?
 
Any client keys that you have issued for key based client authentication are now suspect because the vulnerability specifically allowed an attacker to access client memory that could have contained the secret keys of the client.
 
obsigna said:
xy16644 said:
...
What if you have set /etc/make.conf:
Code:
WITH_OPENSSL_PORT=yes

AFAIK, that flag is only effective if you put before that another one:

Code:
USE_OPENSSL=yes

For the gory details, see /usr/ports/Mk/bsd.openssl.mk.

You may want to check, if all your ports are linked with OpenSSL from the ports. Submit one of the following commands as user root, and go for a coffee.

On FreeBSD 9:
find /usr/local/bin /usr/local/sbin /usr/local/libexec /usr/local/lib -type f | xargs -n1 file -F ' ' | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep "libssl.so.6\|libcrypto.so.6" | cut -f1 -d' ' | sort -u | xargs -n1 pkg_info -W | cut -f6 -d' ' | sort -u | tee ~/openssl_dependencies.txt

On FreeBSD 10:
find /usr/local/bin /usr/local/sbin /usr/local/libexec /usr/local/lib -type f | xargs -n1 file -F ' ' | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep "libssl.so.7\|libcrypto.so.7" | cut -f1 -d' ' | sort -u | xargs -n1 pkg_info -W | cut -f6 -d' ' | sort -u | tee ~/openssl_dependencies.txt

This command will output the OpenSSL dependencies, that are still inked against the base OpenSSL. It will also create a text file ~/openssl_dependencies.txt which can be feeded into portmaster(8) for re-building the ports.

portmaster `cat ~/openssl_dependencies.txt`
rm ~/openssl_dependencies.txt

Note, that most of the ports anyway build against OpenSSL from the ports if this is present, regardless of any flags in /etc/make.conf.

I tried to run your command but received this error:

Code:
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
ldd: /usr/local/lib/python2.7/config/python.o: not a dynamic ELF executable
xargs: pkg_info: No such file or directory

The ONLY entry I have in /etc/make.conf is:

Code:
WITH_OPENSSL_PORT=yes

So I am assuming that ALL my ports are ONLY using the OpenSSL port and NOT the base version?
 
xy16644 said:
I tried to run your command but received this error:

Code:
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
ldd: /usr/local/lib/python2.7/config/python.o: not a dynamic ELF executable
xargs: pkg_info: No such file or directory
The old pkg_* utilities are obsolete. They have been removed from base in FreeBSD 10.

I believe the equivalent of pkg_info -W is pkg which.
 
Beastie said:
xy16644 said:
I tried to run your command but received this error:

Code:
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
ldd: /usr/local/lib/python2.7/config/python.o: not a dynamic ELF executable
xargs: pkg_info: No such file or directory
The old pkg_* utilities are obsolete. They have been removed from base in FreeBSD 10.

I believe the equivalent of pkg_info -W is pkg which.

Yes, on systems with the new generation PKG, pkg_info -W shall be replaced by pkg which. Please excuse my fault.

Please try on FreeBSD 10:
find /usr/local/bin /usr/local/sbin /usr/local/libexec /usr/local/lib -type f | xargs -n1 file -F ' ' | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep "libssl.so.7\|libcrypto.so.7" | cut -f1 -d' ' | sort -u | xargs -n1 pkg which | cut -f6 -d' ' | sort -u | tee ~/openssl_dependencies.txt
 
I just ran the command on a FreeBSD 10 server and I get:

Code:
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
ldd: /usr/local/lib/python2.7/config/python.o: not a dynamic ELF executable
curl-7.36.0
gnupg1-1.4.16_1
pam_ssh_agent_auth-0.9.5
php55-curl-5.5.11
pkg-1.2.7_2
 
xy16644 said:
I just ran the command on a FreeBSD 10 server and I get:

Code:
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
ldd: /usr/local/lib/python2.7/config/python.o: not a dynamic ELF executable
curl-7.36.0
gnupg1-1.4.16_1
pam_ssh_agent_auth-0.9.5
php55-curl-5.5.11
pkg-1.2.7_2

Now feed the entries of ~/openssl_dependencies.txt into portmaster, so it would rebuild the listed ports.
 
Interesting, I just ran portmaster to reinstall these ports:

Code:
curl-7.36.0
gnupg1-1.4.16_1
pam_ssh_agent_auth-0.9.5
php55-curl-5.5.11
pkg-1.2.7_2

and they all reinstalled fine but when I reran your command the same ports were listed!?
 
FYI - the update to 10.0 appears to keep the shared libraries at the same number. These are the files added by p1:

/usr/include/openssl/bn.h
/usr/lib/libcrypto.a
/usr/lib/libcrypto_p.a
/usr/lib/libssl.a
/usr/lib/libssl.so.7
/usr/lib/libssl_p.a
/usr/lib32/libcrypto.a
/usr/lib32/libcrypto.so.7
/usr/lib32/libcrypto_p.a
/usr/lib32/libssl.a
/usr/lib32/libssl.so.7
/usr/lib32/libssl_p.a

I presume this is to prevent having to recompile everything that is dependent on openssl. Or am I missing something?
 
I also have an invariable number of ports insisting on not to being linked against OpenSSL from the ports. On my machine the list is:

Code:
curl-7.36.0
ipsec-tools-0.8.1_4
mpd-5.7
netatalk3-3.1.1,1
pkg-1.2.7_2

These ports don't care about any flags in /etc/make.conf.

For example when configuring curl I see:

Code:
checking for OpenSSL headers version... 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.
 
OK, the base /usr/bin/openssl version shows "OpenSSL 1.0.1e-freebsd 11 Feb 2013", and that was after the 10.0-RELEASE-p1 update. The ports version is up-to-date. So stupid me thought I would mv /usr/bin/openssl /usr/bin/openssl.bak and have it default to the ports version. Working from terminal isn't an issue but starting X gave me a "OpenSSL not found" error and put me back at the command prompt.
 
drhowarddrfine said:
I thought I read that it would still show as version 1e but the patch was in there.
That's how it worked for me. All better now, but still showing same version in base.
 
obsigna said:
I also have an invariable number of ports insisting on not to being linked against OpenSSL from the ports. On my machine the list is:

Code:
curl-7.36.0
ipsec-tools-0.8.1_4
mpd-5.7
netatalk3-3.1.1,1
pkg-1.2.7_2

These ports don't care about any flags in /etc/make.conf.

For example when configuring curl I see:

Code:
checking for OpenSSL headers version... 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

So does this mean they are still vulnerable? Or not?
 
The patch is applied so you should be good. The patch updated the shared libs, but not the header files. This probably isn't a problem as I presume (haven't looked) that the CVE fixes didn't change any function prototypes.

What's happening to the OP above (obsigna) is that curl's configure script is checking the consistency between the libraries and the header files. The patch didn't update the header files so there will be a consistency problem. I'd just modify the configure script to skip that test, and all should be fine.
 
Thanks, I'm happy now. I just wanted to make sure...especially considering the severity of this vulnerability.
 
Somebody tell me if I'm seeing things. I did the updates to openssl, and yet I see conflicting information.
When I run (openssl version) I get v0.9.8y. When I run pkg_info | grep openssl I get v1.0.1_8.

Any suggestions?

Code:
root@server:~ # /usr/bin/openssl version
OpenSSL 0.9.8y 5 Feb 2013

root@server:~ # pkg_info | grep openssl
openssl-1.0.1_8     SSL and crypto library
 
user222 said:
AlbyVA said:
Any suggestions?

My guess is you are comparing two versions...one in /usr/bin and the other in /usr/local/bin.



Doh... Thanks for the sanity check.


Code:
root@system:/usr/local/bin # ls -l open*
-rwxr-xr-x  1 root  wheel  584124 Apr  9 23:55 openssl

root@system:/usr/local/bin # ./openssl version
OpenSSL 1.0.1e 11 Feb 2013
 
AlbyVA said:
user222 said:
AlbyVA said:
Any suggestions?

My guess is you are comparing two versions...one in /usr/bin and the other in /usr/local/bin.



Doh... Thanks for the sanity check.


Code:
root@system:/usr/local/bin # ls -l open*
-rwxr-xr-x  1 root  wheel  584124 Apr  9 23:55 openssl

root@system:/usr/local/bin # ./openssl version
OpenSSL 1.0.1e 11 Feb 2013

Oh crap. That's v1.0.1e Argh!!! Let me start over. I missed a step somewhere.. lol
 
Patch: Success
Buildworld: Crap!!!!

I think I'll go with Plan B.
A wholesale upgrade to FreeBSD v10 since it's already been patched.
These rebuilds never seem to work as intended for me.

Category: contrib
Module: openssl
Announced: 2014-04-08
Affects: All supported versions of FreeBSD.
Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE)



Code:
cc  -O2 -pipe  -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -fstack-protector -Wno-pointer-sign -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bn/bn_lib.c -o bn_lib.o
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bn/bn_lib.c:888: error: redefinition of 'BN_consttime_swap'
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bn/bn_lib.c:836: error: previous definition of 'BN_consttime_swap' was here
*** [bn_lib.o] Error code 1

Stop in /usr/src/secure/lib/libcrypto.
*** [secure/lib/libcrypto__L] Error code 1

Stop in /usr/src.
*** [libraries] Error code 1

Stop in /usr/src.
*** [_libraries] Error code 1

Stop in /usr/src.
*** [buildworld] Error code 1

Stop in /usr/src.
 
Hey guys. I recently did a freebsd-update fetch install and my openssl version is still 1.0.1e-freebsd. How do I update the base binary if freebsd-update doesn't upgrade it?
 
KAG said:
Hey guys. I recently did a freebsd-update fetch install and my openssl version is still 1.0.1e-freebsd. How do I update the base binary if freebsd-update doesn't upgrade it?

The fix for the heartbleed bug has been back ported to OpenSSL 1.0.1e, see http://svnweb.freebsd.org/base?view=revision&revision=264267.

After freebsd-update fetch and freebsd-update install, you won't see a change in the version number of OpenSSL, because it is still version 1.0.1e, albeit patched by the heartbleed and an EC side channel fix.

If you want to be really sure that your services are not vulnerable by the TLS heartbeat BO attack, check it yourself using one of the various scripts on the net, for example: https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl.
 
Back
Top