Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

Question

Are Apache Tomcat servers using Tomcat Native & APR vulnerable to the HeartBleed OpenSSL bug, or does this layer insulate them? http://tomcat.apache.org/native-doc/

HeartBleed OpenSSL bug information: http://heartbleed.com/

On my Apache Tomcat server, I have:

• A vulnerable version of OpenSSL
• Built and installed APR
• Built and installed Tomcat Native using --with-apr and --with-ssl
• Tomcat is handling requests directly. A Connector on port 443 is configured with attributes SSLEnabled, SSLProtocol, SSLCipherSuite, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile
  • SSLProtocol="-ALL +SSLv3 +TLSv1"
  • SSLCipherSuite="ALL:!aNULL:!eNULL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT"

Questions:

• Do versions of Tomcat, APR, or Tomcat Native have any affect on vulnerability?
• Do SSLProtocol or SSLCipherSuite values affect vulnerability?

Answer 1

According to the document you linked to, the APR connector

• Uses OpenSSL for TLS/SSL capabilities (if supported by linked APR library)

Therefore, it would be reasonable to assume that the Tomcat Native Library would be vulnerable to the Heartbleed bug. However, the conditions are different, because Tomcat is written in Java, and Java has its own allocation system (the famous garbage collector) which obtains memory from the OS by huge blocks, quite apart from the zones where OpenSSL obtains its blocks.

Thus, the heartbleed buffer overrun is unlikely to reveal any secret information which exists as Java-based object. It may, however, obtain information which is allocated from the same heap as where OpenSSL obtains its own buffers. In particular, it is possible that the vulnerability may reveal part or all of the private key used by OpenSSL itself.

Answer 2

I've got a tomcat 7.0.29 server on windows that is showing up as vulnerable on the qualys heartbleed scans. It's using APR with this connector configuration in server.xml:

Connector protocol="org.apache.coyote.http11.Http11AprProtocol"
URIEncoding="UTF-8"
port="443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="${catalina.base}/conf/ssl/XXXX.cer" 
SSLCertificateKeyFile="${catalina.base}/conf/ssl/XXXX.key"
SSLCertificateChainFile="${catalina.base}/conf/ssl/XXXX.cer"
SSLPassword="XXXX"
clientAuth="optional" 
SSLProtocol="ALL" 
SSLCipherSuite="ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA"

Brian

Answer 3

Here's a link to tcnative-1.1.29 binaries for Windows complied against apr-1.5.0, openssl-1.0.1g. This is complied against VC 2008, so you will need the Microsoft Visual C++ 2008 Redistributable for Windows 2003 or XP. The files from Juan Calero didn't include win32 and were complied against VC 2010. One or the other might serve your proposes better. You just need to stop tomcat, replace tcnative-1.dll then start tomcat.

Answer 4

I believe tomcat is not vulnerable to heartbleed out of the box.

Yes, the APR library is linked and SSLEngine is on.

<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

But if you look at the server.xml config file of a default tomcat deployment, it's SSL connector uses JSSE not the APR library.

<!-- Define a SSL HTTP/1.1 Connector on port 8443
     This connector uses the BIO implementation that requires the JSSE
     style configuration. When using the APR/native implementation, the
     OpenSSL style configuration is required as described in the APR/native
     documentation -->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS" />
-->

So it shouldn't be exploitable via Heartbleed. Unless you manually changed the SSL connector to use APR, I think it's safe to say, you are not vulnerable.

Speaking of which do you know of any offline tester for heartbleed?

http://alexluca.com/2014/04/10/heartbleed-and-tomcat-out-of-the-box-ssl-config/

Regards,

Alex L.