ThreatSCOPE Use Case: Healing the Heartbleed OpenSSL vulnerability

• November 21, 2019

In this previous post we showed how ThreatSCOPE can be used to identify and analyze the HeartBleed vulnerability in the OpenSSL library. In this post we will show how ThreatSCOPE can be used to insert code to heal it. For this example, the OpenSSL library is used in the common use case of providing SSL for an Apache web server. This web server is taken from an ARM based Raspberry Pi embedded system. We ran this web server on the Raspberry Pi and verified that it’s vulnerable with a HeartBleed test script:

As shown by the output from the script, the server is found to be vulnerable to HeartBleed. To show how we can use ThreatSCOPE to insert code to heal the HeartBleed vulnerability we wrote a small C function which identifies and filters SSL heartbeat packets, which are the ones exploited by HeartBleed. To review the HeartBleed vulnerability, it resulted from an unchecked call to memcpy(), where a client provided both the content that was to be copied as well as the size to be copied. This enabled a malicious user to provide a much longer length than the size of the payload that was actually provided. Based on this, the code for healing this vulnerability identifies malicious heartbeat packets and limits their length field to the length of the payload that was actually provided. We then compiled the source code for this function and used ThreatSCOPE to insert it such that it runs after each SSL packet is received:

After choosing to insert code, ThreatSCOPE brings up a new window for customizing how the code will be inserted. From here we chose the desired insertion location, at the beginning of the basic block that was selected, and to insert this code using a procedure call. Since we are inserting this code as a procedure call we also need to tell ThreatSCOPE which active registers at this point in the program should be mapped to which procedure argument registers. Our filter_heartbeat() procdure takes a single argument which is a pointer to an SSL packet which it will filter. Since the pointer to the SSL packet resides in r11 at this point in the program, we instructed ThreatSCOPE to map r11 to the first argument register, r0. These code insertion options as well as the file name for the new web server executable are shown here:

Finally, after clicking the “Insesrt Code” button, ThreatSCOPE peforms this code insertion and generates a new executable for the Apache web server, with the healing code inserted. Afterwards, it shows the updated control flow graph of the procedure where the code was inserted, side-by-side with the original control flow graph. The new code that was inserted is shown in green:

After performing this code insertion we installed the new Apache web server on the Raspberry Pi and ran it to verify that the HeartBleed vulnerability had been healed. Once again we ran the same HeartBleed test script and targeted the Raspberry Pi:

As shown by the output from the tests script, the HeartBleed vulnerability was successfully healed and the web server can no longer be exploited.

Learn more information about ThreatSCOPE by downloading BlueRiSC’s recent whitepaper. Visit our Contact Us web page or email sales@bluerisc.com to schedule a one-hour WebEx meeting, and BlueRiSC will provide a live demonstration of ThreatSCOPE’s unique features and capabilities.