Skip to Content

SAP, OpenSSL, and Heartbleed

I'm sure by now everyone has heard more than they wanted to about the latest vulnerability sweeping the Internet. As far as I can tell, SAP NetWeaver systems don't have any built-in OpenSSL components and shouldn't be vulnerable, but I'm not 100% sure about this. I'm a little surprised that I can't find any mention of Heartbleed in any of the forums today.

So, can anyone state with authority that I'm correct about this, and NetWeaver (ABAP and/or Java) systems are not inherently vulnerable to this flaw?



Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

5 Answers

  • Best Answer
    Apr 11, 2014 at 11:02 AM

    Please have a look at this security notification:

    It says: At the current state of investigations we have no indications that SAP NetWeaver and SAP HANA are affected.

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 11, 2014 at 09:18 PM

    By uncommenting the various 'print' messages in the script, and ultimately using the original script, unmodified, which allows interactive testing with any tcp port of one host at a time, I figured out a bit about why I was getting the erroneous 'No SSL' messages.

    The full output when scanning an https dispatcher port on a J2EE server (v 7.01) returns:


    Sending Client Hello...

    Waiting for Server Hello...

    ... received message: type = 22, ver = 0302, length = 1782

    Unexpected EOF receiving record header - server closed connection

    Server closed connection without sending Server Hello.

    In the dispatcher default trace a warning message appears:

    Cannot get input and output streams from socket. Connection is not initialized.

    [EXCEPTION] Connection closed by remote host.

    at Source)


    So, the dispatcher doesn't seem to handle the initialization handshake of the test script. That in itself is not an indication of vulnerability or lack thereof. However, it reinforces that J2EE is using the IAIK suite and not OpenSSL, which reinforces the statement Stephan highlighted currently found at the top of, in which SAP states they currently have no indication of being vulnerable in NetWeaver.

    I'm going to assume we're ok until and unless we see otherwise in a message from SAP. Thanks everyone who weighed in on this discussion.

    Best regards,


    Add comment
    10|10000 characters needed characters exceeded

  • Apr 15, 2014 at 06:23 PM

    A final follow-up on this thread: SAP has updated Note 2004805 with the status for many of their products. There are some products that are vulnerable, but AS ABAP, AS Java, and HANA are not impacted, as we were all surmising.

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 09, 2014 at 09:45 PM

    By default SAP uses SAP Cryptographic Library (or CommonCryptoLib in most recent releases) for SSL so the question becomes does SAP's library share code with the vulnerable TLS implementation in OpenSSL.

    Add comment
    10|10000 characters needed characters exceeded

    • Most websites today seem to be lacking Perfect (😉) Forward Secrecy, unfortunately, probably because they opt for greater compatibility with older browsers. I'd like to see that implemented much more widely everywhere.

  • Apr 10, 2014 at 09:09 PM

    Using a Python script found at heartbleed-masstest/ at master · musalbas/heartbleed-masstest · GitHub I was able to test for vulnerability in our internal SRM and ECC systems, as well as our web dispatcher, and all came up clean. However, the script is not intelligent enough to work with systems that use TCP ports other than 443 for SSL (even if you modify line 125 where it seems to hard-code 443 into the call), and other than our dispatcher our portal systems all use a mix of the SAP defaults of 50101 or 50001, depending on instance number. I'm no Python expert -- not even a novice -- so I'm not sure why changing line 125 didn't make this work. Perhaps one of you will have more luck.

    Anyway, at this time I feel confident that ABAP systems (and web dispatchers) are not vulnerable. I still don't have proof positive on J2EE systems yet. It seems like it would be easier to debug the Python script than to modify a test portal to use TCP 443 instead of 50101, but for me the latter at least is something I know how to do! It just feels a bit like the proverbial bus to cross the street, if you know what I mean.

    Add comment
    10|10000 characters needed characters exceeded

    • True. In my case, I am trying to test internal systems for which I am the system administrator. If there's anyone with a right to test them, it's me. I have also been involving our internal network security team, although they are not specifically SAP-oriented, but more Windows Server, router/firewall, and general Internet exposure oriented. However, you make a very good point, and I am not advocating that anyone go out and test other organizations' SAP systems (unless they have contracted you to do so).