Date: Sat, 13 Jun 2015 12:50:50 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: michelle@sorbs.net Cc: fbsd@xtaz.co.uk, ml@netfence.it, freebsd-ports@FreeBSD.org Subject: Re: OpenSSL Security Advisory [11 Jun 2015] Message-ID: <201506131950.t5DJooEA021169@gw.catspoiler.org> In-Reply-To: <557C2230.4070502@sorbs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 it. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201506131950.t5DJooEA021169>