freeradius 3.0.13 refusing to start with Heartbleed-unaffected OpenSSL version
Hi, having trouble getting radiusd to work because of openssl: CLI debugging: root@$HOSTNAME:/etc/raddb# openssl version OpenSSL *1.0.2k* 26 Jan 2017 root@$HOSTNAME:/etc/raddb# cat radiusd.conf | grep allow_vulnerable # allow_vulnerable_openssl: Allow the server to start with * allow_vulnerable_openssl = yes* root@$HOSTNAME:/etc/raddb# hostnamectl Static hostname: $HOSTNAME Icon name: computer-vm Chassis: vm Machine ID: $CENSORED Boot ID: $CENSORED Virtualization: vmware Operating System: Debian GNU/Linux 8 (jessie) Kernel: Linux 3.16.0-4-amd64 Architecture: x86-64 root@$HOSTNAME:/etc/raddb# radiusd -X FreeRADIUS Version 3.0.13 [snip] Debugger not attached Refusing to start with libssl version OpenSSL 1.0.1t 3 May 2016 0x1000114f (1.0.1t release) (in range 1.0.1 release - 1.0.1t rele) Security advisory CVE-2016-6304 (OCSP status request extension) For more information see https://www.openssl.org/news/secadv/20160922.txt Once you have verified libssl has been correctly patched, set security.allow_vulnerable_openssl = 'CVE-2016-6304' The same error message when entering allow_vulnerable_openssl = 'CVE-2016-6304' in radiusd.conf No matter what I search for - every search results in something similar than https://lalitvc.wordpress.com/2014/06/26/freeradius-refusing-to-start-with-l... Do I have to recompile FreeRADIUS after a new installation of OpenSSL? Yours, Konstantin
On Apr 20, 2017, at 9:56 AM, Konstantin Knaab-Hinrichs via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
having trouble getting radiusd to work because of openssl:
CLI debugging:
root@$HOSTNAME:/etc/raddb# openssl version OpenSSL *1.0.2k* 26 Jan 2017 ... Debugger not attached Refusing to start with libssl version OpenSSL 1.0.1t 3 May 2016 0x1000114f (1.0.1t release) (in range 1.0.1 release - 1.0.1t rule)
You have multiple versions of OpenSSL installed on your system. Don't do that. FreeRADIUS doesn't magically detect OpenSSL 1.0.1t when you actually have 1.0.2k installed. It detects 1.0.1t because 1.0.1t *is* installed, and *is* being used by FreeRADIUS.
Do I have to recompile FreeRADIUS after a new installation of OpenSSL?
Yes. Because of historic issues with OpenSSL breaking their APIs in minor releases. OpenSSL is fixing their APIs. We will likely relax this check for OpenSSL 1.1.0 and later. Alan DeKok.
root@$HOSTNAME:/etc/raddb# dpkg --get-selections | grep libssl libssl-dev:amd64 install libssl-doc install libssl1.0.0:amd64 install root@$HOSTNAME:/etc/raddb# apt-get purge libssl-dev [snip] Entfernen von libssl-dev:amd64 (1.0.1t-1+deb8u6) ... dpkg: Warnung: Während Entfernens von libssl-dev:amd64 ist Verzeichnis »/usr/include/openssl« nicht leer, wird daher nicht gelöscht // directory not empty root@$HOSTNAME:/etc/raddb# apt-get autoremove && apt-get autoclean [snip] Die folgenden Pakete werden ENTFERNT: // autoremoved packages libssl-doc zlib1g-dev [snip] root@$HOSTNAME:/etc/raddb# apt-get update && apt-cache madison libssl-dev libssl-dev | 1.0.1t-1+deb8u6 | http://security.debian.org/ jessie/updates/main amd64 Packages libssl-dev | 1.0.1t-1+deb8u5 | http://ftp.de.debian.org/debian/ jessie/main amd64 Packages openssl | 1.0.1t-1+deb8u5 | http://ftp.de.debian.org/debian/ jessie/main Sources openssl | 1.0.1k-3+deb8u3 | http://security.debian.org/ jessie/updates/main Sources openssl | 1.0.1t-1+deb8u6 | http://security.debian.org/ jessie/updates/main Sources root@$HOSTNAME:/etc/raddb# dpkg --get-selections | grep libssl1 libssl1.0.0:amd64 install root@$HOSTNAME:/etc/raddb# dpkg --get-selections | grep libssl-dev root@$HOSTNAME:/etc/raddb# openssl version OpenSSL 1.0.2k 26 Jan 2017 -> The only libssl I have installed should be libssl1.0.0 which should not be in the mentioned 1.0.1 - 1.0.1t rule. OpenSSL 1.0.2k shouldn't be in a blocked range too. root@$HOSTNAME:/home/$USER/freeradius3/freeradius-server-3.0.13# ./configure --with-raddbdir=/etc/raddb root@$HOSTNAME:/home/$USER/freeradius3/freeradius-server-3.0.13# make [snip] scripts/boiler.mk:635: recipe for target 'build/objs/src/modules/rlm_eap/libeap/eap_tls.lo' failed make: *** [build/objs/src/modules/rlm_eap/libeap/eap_tls.lo] Error 1 According to apt-cache madison and Google there isn't an unblocked libssl-dev available to install. Why doesn't it work when allow_vulnerable_openssl = 'CVE-2016-6304' is set in radiusd.conf - as the debug mode of raddb says? Do I have to ./configure with another option saying that I don't want the blocked range - because I checked OpenSSL already? Yours, Konstantin 2017-04-20 16:05 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Apr 20, 2017, at 9:56 AM, Konstantin Knaab-Hinrichs via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
having trouble getting radiusd to work because of openssl:
CLI debugging:
root@$HOSTNAME:/etc/raddb# openssl version OpenSSL *1.0.2k* 26 Jan 2017 ... Debugger not attached Refusing to start with libssl version OpenSSL 1.0.1t 3 May 2016
0x1000114f
(1.0.1t release) (in range 1.0.1 release - 1.0.1t rule)
You have multiple versions of OpenSSL installed on your system. Don't do that.
FreeRADIUS doesn't magically detect OpenSSL 1.0.1t when you actually have 1.0.2k installed. It detects 1.0.1t because 1.0.1t *is* installed, and *is* being used by FreeRADIUS.
Do I have to recompile FreeRADIUS after a new installation of OpenSSL?
Yes. Because of historic issues with OpenSSL breaking their APIs in minor releases.
OpenSSL is fixing their APIs. We will likely relax this check for OpenSSL 1.1.0 and later.
Alan DeKok.
On 21-04-17 08:50, Konstantin Knaab-Hinrichs via Freeradius-Users wrote:
root@$HOSTNAME:/etc/raddb# apt-get update && apt-cache madison libssl-dev libssl-dev | 1.0.1t-1+deb8u6 | http://security.debian.org/ jessie/updates/main amd64 Packages libssl-dev | 1.0.1t-1+deb8u5 | http://ftp.de.debian.org/debian/ jessie/main amd64 Packages openssl | 1.0.1t-1+deb8u5 | http://ftp.de.debian.org/debian/ jessie/main Sources openssl | 1.0.1k-3+deb8u3 | http://security.debian.org/ jessie/updates/main Sources openssl | 1.0.1t-1+deb8u6 | http://security.debian.org/ jessie/updates/main Sources root@$HOSTNAME:/etc/raddb# dpkg --get-selections | grep libssl1 libssl1.0.0:amd64 install root@$HOSTNAME:/etc/raddb# dpkg --get-selections | grep libssl-dev root@$HOSTNAME:/etc/raddb# openssl version OpenSSL 1.0.2k 26 Jan 2017
There is a difference here, apt shows 1.0.1t-1+deb8u6 as most recent version (which is the most recent version on my Jessie install too, so that's fine), but `openssl version` shows a different version (1.0.2 instead of 1.0.1). Did you install openssl from source as well? I wouldn't be surprised if `which openssl` showed something other than /usr/bin/openssl which is where the packages are installed.
According to apt-cache madison and Google there isn't an unblocked libssl-dev available to install. Why doesn't it work when allow_vulnerable_openssl = 'CVE-2016-6304' is set in radiusd.conf - as the debug mode of raddb says? Do I have to ./configure with another option saying that I don't want the blocked range - because I checked OpenSSL already?
If you're actually using the Debian-packages for OpenSSL, there is not much added value by letting freeradius check for vulnerabilities. Mostly OpenSSL of Debian is patched faster than you'd upgrade your RADIUS server, and because fixes are backported the version check doesn't make much sense either. You could pass --disable-openssl-version-check to the build to disable openssl version checks, or build the Debian packages (http://wiki.freeradius.org/building/Debian-and-Ubuntu) which include this switch by default. -- Herwin Weststrate
participants (3)
-
Alan DeKok -
Herwin Weststrate -
Konstantin Knaab-Hinrichs