On 8 Apr 2014, at 14:28, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 08/04/14 13:41, Alan DeKok wrote:
Yes. And unfortunately there's no run-time check to say that OpenSSL has been patched to address the vulnerability. <sigh>
And AFAICT no run-time way to disable the extension. Grumble.
Yep. That was pretty much the first thing I checked this morning. I agree, adding runtime checks is the better option. I actually added a runtime check first, and was going to add a configure time check, but after discussions with Alan offlist we decided it was better to just leave it. As per your suggestion there's now a security.allow_vulnerable_openssl configuration item which enables or disables the security check. # # allow_vulnerable_openssl: Allow the server to start with # versions of OpenSSL known to have critical vulnerabilities. # # This check is based on the version number reported by libssl # and may not reflect patches applied to libssl by # distribution maintainers. # allow_vulnerable_openssl = no If you have a potentially vulnerable version of OpenSSL the server will print: Refusing to start with libssl version %s (in range 1.0.1 - 1.0.1f). Security advisory CVE-2014-0160 (Heartbleed) For more information see http://heartbleed.com end exit. radiusd -xv will now print out the decoded version number to give more information about the local openssl patch level. Though as it's only a 4 bit integer, (and currently 15 on Ubuntu 12.04) it's probably not a whole lot of use. Alan is backporting these features to v2.x.x Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2