Forum Discussion

Paul_Roberts_16's avatar
Paul_Roberts_16
Icon for Nimbostratus rankNimbostratus
Jun 09, 2014

SSL irregularities in 10.2.4/11.4.1 LTMs. Vulnerable to Heartbleed or not?

So our network security team regularly sweeps our network looking for unpatched issues, and this week we recieved a whole pile of alerts about our LTMs and GTMs for the Heartbleed vulnerability on port 4353/tcp. I was under the impression (from testing them myself, from logging into the boxes and personally eyeballing the openssl versions from the inside, and from F5's pronouncements on the matter) that these boxes were supposed to be not vulnerable, primarily because the OpenSSL build in play did not yet even understand the TLS heartbeat extension. Very curious.

 

Apparently this may not be entirely correct. Looking more closely at this particular port (apparently used so the LTMs and GTMs can all find each other readily) it's apparently bound by the big3d binary--which is statically linked and stripped and could very well have been compiled against a vulnerable version of OpenSSL. This is more than just speculation as directly querying the port with OpenSSL from the command line shows the following:

 

$ openssl s_client -connect some.random.ltm.we.have:4353 -tlsextdebug
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - 
TLS server extension "session ticket" (id=35), len=0
**TLS server extension "heartbeat" (id=15), len=1**
0000 - 01
(server summarily hangs up after issuing the certificate)

Seeing as how there isn't a version of OpenSSL prior to 1.0.1g that understood the TLS heartbeat extention and wasn't using the flawed code, I suspect we might have a problem with equipment being vulnerable after people have been told it wasn't. Has anyone addressed this directly with F5 yet?

 

application delivery
BIG-IP DNS
LTM
management
security

4 Replies

Sort By
  • mimlo_61970's avatar
    mimlo_61970
    Icon for Cumulonimbus rankCumulonimbus
    Jun 09, 2014

    Try running strings against /usr/sbin/big3d and see what you get. I only have an 11.2.1 gtm/ltm available, but it appears to have been compiled with 0.9.8y. I also do not see the heartbeat extension listed as available on port 4353

    strings /usr/sbin/big3d | grep OpenSSL

TLSv1 part of OpenSSL 0.9.8y 5 Feb 2013
OpenSSL 0.9.8y 5 Feb 2013
SSLv2 part of OpenSSL 0.9.8y 5 Feb 2013
SSLv3 part of OpenSSL 0.9.8y 5 Feb 2013
....
  • Paul_Roberts_16's avatar
    Paul_Roberts_16
    Icon for Nimbostratus rankNimbostratus
    Jun 09, 2014

    Joy. It looks like they used parts of OpenSSL 1.0.1e to build this thing sitting in /shared/bin/big3d. The one in /usr/sbin is still 0.9.8y at least tho'.

     

    After asking around here quite a bit, it appears the Enterprise Manager upgraded the thing on us.

     

  • mimlo_61970's avatar
    mimlo_61970
    Icon for Cumulonimbus rankCumulonimbus
    Jun 09, 2014

    I have an 11.4.1 standalone LTM and both versions of big3d show 0.9.8y, you may be correct that EM upgraded it and used a vulnerable OpenSSL.

     

    I assume you are opening a support ticket?

     

  • Paul_Roberts_16's avatar
    Paul_Roberts_16
    Icon for Nimbostratus rankNimbostratus
    Jun 09, 2014

    I will eventually, but I wanted to make sure I had my ducks very in a row before breaching the subject. They're not going to be terribly happy having to do an about-face over whether or not the Enterprise Manager is vulnerable when it's combined with the little detail that it will also make otherwise safe versions vulnerable.

     

    I note with some concern that the page on the matter does not say anything about the relevant versions of Enterprise Manager actually being hotfixed or even patched. See also http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html

     

    If they didn't actually fix that version then EM is likely still handing out a vulnerable binary because no one thought to look very closely at the statically linked binary with 1.0.1e-fips sealed up inside it.

     

Related Content