# OpenSSL update



## xy16644 (Apr 8, 2014)

I see there is a vulnerability in OpenSSL:

https://www.openssl.org/news/secadv_20140407.txt

I use the OpenSSL port rather than the built in FreeBSD version. I ran `portmaster -a` today and I see that an updated version of OpenSSL is available (version 1.0.1g). 

Do I need to recompile all dependant ports if I update my OpenSSL port? Theres nothing mentioned in /usr/ports/UPDATING about doing this but I just wanted to make sure.

Thanks.


----------



## obsigna (Apr 8, 2014)

There is no need to recompile the dependant ports. Restarting the services which provide SSL/TLS by the way of OpenSSL would be good, though.


----------



## kpa (Apr 8, 2014)

Every single port that uses OpenSSL uses so called dynamic linking to link the libraries into them and that means there's no need to recompile the dependent ports if the OpenSSL port is updated. Of course you have to restart any services that have the old copy of the library loaded in memory to make them use of the updated version of the dynamic link library.


----------



## SirDice (Apr 8, 2014)

kpa said:
			
		

> Every single port that uses OpenSSL uses so called dynamic linking to link the libraries into them and that means there's no need to recompile the dependent ports if the OpenSSL port is updated.


Not unless the version of the library changes, or more specifically its ABI. But nothing changes with this bug fix so nothing will have to be rebuild (except OpenSSL itself obviously).

There's more information about this bug here: http://heartbleed.com/

It's quite a bad one, definitely make sure your systems are updated.


----------



## seanthingee (Apr 8, 2014)

I have a similar question, however I am not running OpenSSL from ports. What is the recommended course of action when running openssl from the base installation?

Also, is there a utility similar to "pkg audit" that'll show me vulnerabilities in the base system?

Thanks!


----------



## kpa (Apr 8, 2014)

The vulnerability is not as bad as it has been portrayed in the media. For the attack to succeed someone has to first be able to be a "man in the middle" by tampering with DNS for example. Even if the attack succeeds it does not reveal information from the server end of the connection, only from the client.

http://lists.freebsd.org/pipermail/freebsd-security/2014-April/007410.html


----------



## xy16644 (Apr 8, 2014)

I just updated my OpenSSL port and when I run `openssl version` it still says:


```
OpenSSL 1.0.1e-freebsd 11 Feb 2013
```

Am I running the patched version now?


----------



## kpa (Apr 8, 2014)

xy16644 said:
			
		

> I just updated my OpenSSL port and when I run `openssl version` it still says:
> 
> 
> ```
> ...



You have to make sure you run the port version and not the base system version.

`/usr/local/bin/openssl version`


----------



## xy16644 (Apr 8, 2014)

Thanks @kpa!

It is the latest version as of today:


```
OpenSSL 1.0.1g 7 Apr 2014
```

I also restarted Postfix, Apache and Dovecot.

It OpenSSH affected at all by this vulnerability?


----------



## kpa (Apr 8, 2014)

xy16644 said:
			
		

> Thanks @kpa!
> 
> It is the latest version as of today:
> 
> ...



I'm inclined to say no since SSH doesn't use SSL/TLS, at least not in its default configuration.


----------



## SirDice (Apr 8, 2014)

Perhaps it should be stressed that it's the implementation that was faulty in this case, the protocol itself isn't affected. In other words it was code specific to OpenSSL that had the bug. 

I can't recall any specific ports from the top of my head but be careful if you have any statically built ports linked to the old OpenSSL libraries. You will have to rebuild those in order to upgrade the statically linked in libraries.


----------



## kpa (Apr 8, 2014)

It may turn out that FreeBSD base was never vulnerable because the extension where the vulnerability was discovered in is disabled by default in FreeBSD base, keep an eye on this thread on the mailing list:

http://lists.freebsd.org/pipermail/freebsd-security/2014-April/007419.html

If this turns out to be true then only the ports version of OpenSSL was vulnerable and not for very long after the vulnerability was discovered.


----------



## obsigna (Apr 8, 2014)

In the last past hours a lot of test facilities were provided on various sites in the net. For checking my servers, I used a perl script provided on GitHub by Steffen Ullrich:

https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl

I updated OpenSSL to 1.0.1g today in the morning and my machines are not vulnerable.


----------



## xy16644 (Apr 8, 2014)

I'm not sure how good this check is but when I ran this it said I am not vulnerable:

http://rehmann.co/projects/heartbeat/


```
Please be patient as the tests are run! (Up to 30 seconds!)
It appears that your SSL is running with heartbeat enabled, running further tests...

Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 66
 ... received message: type = 22, ver = 0302, length = 2817
 ... received message: type = 22, ver = 0302, length = 587
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
Unexpected EOF receiving record header - server closed connection

No heartbeat response received, server likely not vulnerable
```


----------



## xy16644 (Apr 8, 2014)

A great place to test if you are vulnerable from the Heartbleed attack is at SSL Labs:

https://www.ssllabs.com/ssltest

This is how my test result looked:


----------



## kpa (Apr 9, 2014)

It turned out the base system OpenSSL is vulnerable in all supported versions of FreeBSD. A security advisory with the instructions how to update was just released:

http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc


----------



## Petz (Apr 9, 2014)

kpa said:
			
		

> It turned out the base system OpenSSL is vulnerable in all supported versions of FreeBSD. A security advisory with the instructions how to update was just released:
> 
> http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc



Are those instructions correct for FreeBSD 10.0-RELEASE-p1?  Specifically the below.


> 3) To update your vulnerable system via a binary patch:
> 
> Systems running a RELEASE version of FreeBSD on the i386 or amd64
> platforms can be updated via the freebsd-update(8) utility:
> ...




As it looks like there is no updates available.


```
root@ip-172-31-6-227:~ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.0-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 10.0-RELEASE-p1.
root@ip-172-31-6-227:~ # freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
root@ip-172-31-6-227:~ # ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013
root@ip-172-31-6-227:~ # uname -a
FreeBSD ip-172-31-6-227 10.0-RELEASE-p1 FreeBSD 10.0-RELEASE-p1 #0: Tue Apr  8 06:45:06 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
```


----------



## Petz (Apr 9, 2014)

Silly me, should have checked the actual dates on SSL and the corrected section in the advisory "10.0-RELEASE-p1". I guess this already has the update.


```
root@ip-172-31-6-227:/etc # openssl version -a
OpenSSL 1.0.1e-freebsd 11 Feb 2013
built on: date not available
platform: FreeBSD-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: cc
OPENSSLDIR: "/etc/ssl"

root@ip-172-31-6-227:/etc # ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013
```


----------



## xy16644 (Apr 9, 2014)

If I use OpenSSL from ports do I still need to apply this patch to OpenSSL in base?


----------



## SirDice (Apr 9, 2014)

xy16644 said:
			
		

> If I use OpenSSL from ports do I still need to apply this patch to OpenSSL in base?


Better be safe than sorry. You may still have ports linked to the base OpenSSL.


----------



## xy16644 (Apr 9, 2014)

SirDice said:
			
		

> xy16644 said:
> 
> 
> 
> ...



What if you have set /etc/make.conf:


```
WITH_OPENSSL_PORT=yes
```

I do agree that you should apply the patch anyway but I'm just curious if you need this patch when your ports have been compiled to use the OpenSSL port rather.


----------



## obsigna (Apr 9, 2014)

xy16644 said:
			
		

> ...
> What if you have set /etc/make.conf:
> 
> ```
> ...



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


```
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 linked against the base OpenSSL. It will also create a text file ~/openssl_dependencies.txt which can be feed 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.


----------



## AlbyVA (Apr 9, 2014)

*OpenSSL 'Heartbleed' vulnerability*

Is there a version upgrade for this OpenSSL vulnerability? I checked my version and I'm running v1.0.1-8 which is also showing it's up to date.



```
[system: (tcsh):30] pkg_info | grep openssl
openssl-1.0.1_8     SSL and crypto library


[system: (tcsh):31] pkg_version | grep openssl
openssl                             =

[system: (tcsh):32] pkg_add -r openssl
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.2-release/Latest/openssl.tbz... Done.
pkg_add: package 'openssl-1.0.1_8' or its older version already installed
```




TA14-098A: OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)

NCCIC / US-CERT

National Cyber Awareness System:

TA14-098A: OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)
<https://www.us-cert.gov/ncas/alerts/TA14-098A>
04/08/2014 08:46 AM EDT

Original release date: April 08, 2014


      Systems Affected

  * OpenSSL 1.0.1 through 1.0.1f
  * OpenSSL 1.0.2-beta


----------



## SirDice (Apr 9, 2014)

*Re: OpenSSL 'Heartbleed' vulnerability*



			
				AlbyVA said:
			
		

> Is there a version upgrade for this OpenSSL vulnerability? I checked my version and I'm running v1.0.1-8 which is also showing it's up to date.


http://www.vuxml.org/freebsd/5631ae98-b ... 43978.html
http://www.freebsd.org/security/advisor ... penssl.asc


----------



## AlbyVA (Apr 9, 2014)

obsigna said:
			
		

> xy16644 said:
> 
> 
> 
> ...





 Thanks Obsigna. This fix/patch worked like a charm.


----------



## Crivens (Apr 9, 2014)

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?


----------



## kpa (Apr 9, 2014)

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.


----------



## xy16644 (Apr 9, 2014)

obsigna said:
			
		

> xy16644 said:
> 
> 
> 
> ...



I tried to run your command but received this error:


```
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:


```
WITH_OPENSSL_PORT=yes
```

So I am assuming that ALL my ports are ONLY using the OpenSSL port and NOT the base version?


----------



## Beastie (Apr 9, 2014)

xy16644 said:
			
		

> I tried to run your command but received this error:
> 
> 
> ```
> ...


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`.


----------



## obsigna (Apr 9, 2014)

Beastie said:
			
		

> xy16644 said:
> 
> 
> 
> ...



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`


----------



## xy16644 (Apr 9, 2014)

I just ran the command on a FreeBSD 10 server and I get:


```
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
```


----------



## obsigna (Apr 9, 2014)

xy16644 said:
			
		

> I just ran the command on a FreeBSD 10 server and I get:
> 
> 
> ```
> ...



Now feed the entries of ~/openssl_dependencies.txt into portmaster, so it would rebuild the listed ports.


----------



## xy16644 (Apr 9, 2014)

Interesting, I just ran portmaster to reinstall these ports:


```
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!?


----------



## fatsailor (Apr 9, 2014)

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?


----------



## obsigna (Apr 9, 2014)

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:


```
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:


```
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.
```


----------



## tzoi516 (Apr 9, 2014)

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 (Apr 10, 2014)

I thought I read that it would still show as version 1e but the patch was in there.


----------



## user222 (Apr 10, 2014)

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.


----------



## xy16644 (Apr 10, 2014)

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:
> 
> 
> ```
> ...



So does this mean they are still vulnerable? Or not?


----------



## fatsailor (Apr 10, 2014)

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.


----------



## xy16644 (Apr 10, 2014)

Thanks, I'm happy now. I just wanted to make sure...especially considering the severity of this vulnerability.


----------



## AlbyVA (Apr 11, 2014)

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?


```
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 (Apr 11, 2014)

AlbyVA said:
			
		

> Any suggestions?



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


----------



## AlbyVA (Apr 11, 2014)

user222 said:
			
		

> AlbyVA said:
> 
> 
> 
> ...





Doh...    Thanks for the sanity check.



```
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 (Apr 11, 2014)

AlbyVA said:
			
		

> user222 said:
> 
> 
> 
> ...



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


----------



## AlbyVA (Apr 11, 2014)

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)




```
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.
```


----------



## KAG (Apr 12, 2014)

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?


----------



## obsigna (Apr 12, 2014)

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.


----------

