OpenSSL Security Advisory [11 Jun 2015]

Don Lewis truckman at
Sat Jun 13 19:51:03 UTC 2015

On 13 Jun, Michelle Sullivan wrote:
> Matt Smith wrote:
>> On Jun 13 13:13, Michelle Sullivan wrote:
>>> Don Lewis wrote:
>>>> On 13 Jun, Michelle Sullivan wrote:
>>>>> SSH would be the biggie that most security departments are scared
>>>>> of...
>>>> Well, ssh is available in ports, though I haven't checked to see
>>>> that it
>>>> picks up the correct version of openssl.
>>> Problem is it doesn't have 'overwrite base' anymore - and
>>> openssh-portable66 which does have overwrite base is now marked
>>> depreciated... which means one would have to be very careful about how
>>> they use SSH in production as both server and client...  Server is
>>> easier as it has a different _enable identifier... but the client is not
>>> distinguishable so unless one puts /usr/local/bin in their permanent
>>> path as a priority over /usr/bin one will use the wrong version.
>> I put WITHOUT_OPENSSH=yes in /etc/src.conf. Then run make delete-old
>> and make delete-old-libs in /usr/src. This removes the base version
>> which means you don't have this issue any longer. I do the same thing
>> with NTP and Unbound as well.
>> Obviously this makes more sense if like me you do source based stuff
>> rather than using freebsd-update. I'm not sure if you can do similar
>> with binary based upgrades?
> 57 servers around the world that I have to maintain, patch and upgrade
> at the same time as devel and maintain my applications... yeah I don't
> do source stuff ;-)
> It would be useful to have that option in freebsd-update.
>> The other alternatives are as you say, put /usr/local/bin before
>> /usr/bin in the $PATH. Or add an alias for commands like ssh to point
>> to the ports version. These methods aren't quite as clean though.
> Not clean and very error prone... replace base was a lot cleaner and
> less error prone... but then you never know the people in security might
> surprise us and put out a version of base with openssl 1.0.2b in it -
> this would be a real bonus for a lot of people and take us a little bit
> away from debian where you can wait months/years for an update.... and
> then sometimes only if you upgrade your system to include features that
> you don't want.

Something to consider is building your own customized releases and
setting up your own freebsd-update server.  It's an additional headache,
but would allow you to eliminate some possible additional hazards, such
as the setuid rsh and rlogin.  I'm thinking about doing it here.  I
generally track -STABLE and have some src.conf tweaks, so I'm used to
doing source upgrades, but some of my machines are pretty slow and being
able to keep them up to date with freebsd-update would be a time saver.

Upgrading base openssl to 1.0.2 in an existing release branch is pretty
much not going to happen because of the ABI change.  A freebsd-update
that did such a thing would instantly break all non-base applications
that were linked to base openssl.  FreeBSD is not unique in this regard.
For instance, RHEL 5 is supported as a production release through March
2017, with extended support available through November 2020.  It is
still using openssl 0.98.  It'll be interesting to see what Red Hat does
once openssl 0.98 goes EOL at the end of 2015.  I suspect that Red Hat
will continue to maintain 0.98 internally and backport security fixes to

The only branch where ABI changes is allowed is HEAD, so  until we can
change the openssl ABI in FreeBSD 11 up until FreeBSD 11.0-RELEASE.
I suspect that sometime before that point, we will remove openssl from
the the ABI by making it a private library in base so that its only
consumers are other applications in base.  That would allow us to
upgrade the openssl version at any time, since the freebsd-update run
that installed the new openssl would also install the new versions of
the affected base applications.  Ports would use only the ports version
of openssl, and updates there would also be atomic.  There are a number
of problems to solve to get from here to there, such as the linkage
between gssapi and libfetch to openssl.  Also pkg might need to bundle
its own private copy of openssl.

More information about the freebsd-ports mailing list