Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?
share|improve this question
    
Confirmed my app was vulnerable according to filippo.io/Heartbleed After upgrading OpenSSL, simply restarting Tomcat eliminated the vulnerability. Re-compiling APR or Tomcat Native was not necessary. –  Arlo Apr 8 at 23:27
    
This is a really important question. Tomcat is installed by a great many apps on public facing nets (e.g. all the Atlassian products, for example) –  samsmith Apr 9 at 13:57
    
If someone is interested, I've managed to build a version of tc-native for Windows X64 uisng OpenSSL 1.0.1g. I couldn't find any updated binaries. db.tt/VVeDe4t7 –  Juan Calero Apr 10 at 7:17
    
For those using binary builds, there's a Bug regarding updating the Tomcat Native builds: issues.apache.org/bugzilla/show_bug.cgi?id=56363 –  Arlo Apr 10 at 21:35

4 Answers 4

up vote 11 down vote accepted

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.

share|improve this answer
    
Just because OpenSSL is linked in doesn't mean that it's exploitable via the Heartbleed bug. Maybe it is, but your answer seems cautionary and speculative rather than authoritative. –  200_success Apr 8 at 18:16
3  
The linked document is pretty clear about the point of APR+native being to do the SSL/TLS with OpenSSL, from which it is pretty clear that the code chunk in which the bug is will be invoked. –  Thomas Pornin Apr 8 at 18:47
    
@ThomasPornin Can a static vulnerability analysis be %100 reliable, or should we focus on how to identify potential problem sites and how to update them? –  samsmith Apr 9 at 14:51

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

share|improve this answer

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.

share|improve this answer
    
Any reassurances that the patch is safe? –  TildalWave Apr 10 at 18:30
    
I would understand not wanting to use a DLL complied by a random guy on the internet. I provided the scan results from clamav in the zip. I've tested the library using the hb-test.py script. –  user44127 Apr 10 at 23:05
    
tcnative compiled against openssl 1.0.1g from Apache folks: people.apache.org/~mturk/native/1.1.30 –  Brian O'Nolan Apr 13 at 23:39

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.

share|improve this answer
    
Courtesy of Jared Stafford: rehmann.co/projects/heartbeat/ssltest.py –  Deer Hunter Apr 11 at 6:30
    
Apache apparently disagrees: issues.apache.org/bugzilla/show_bug.cgi?id=56363 –  Brian O'Nolan Apr 13 at 23:38
    
It is vulnerable if you enable APR Connector for HTTPS. But Out Of The Box it's not enabled. It's the difference between org.apache.coyote.http11.Http11Protocol AND org.apache.coyote.http11.Http11AprProtocol. And some other config changes since you need to update other values if you switch to APR. And read the Native/ARP docs for that. –  Alex Apr 14 at 7:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.