Author - Sivakumar RR
OpenSSL is robust commercial-grade, a full featured tool kit for the Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols. It also a general purpose cryptography library.
– https://openssl.org
Above mentioned is the short description of OpenSSL from it’s creators. For those who are not familiar with this library, in short OpenSSL plays a key role in securing internet communication across the globe. While browsing you may have seen websites which have it’s address begin with “http” and “https”, when you load the website which belongs to “http” in your browser, usually it shows the “connection insecure warning” where “https” websites indicated as secure communication. To understand how Heartbleed works, we have to discuss a bit about the TLS/SSL standard.
What’s the difference between HTTP & HTTPS?
It’s simple, in “http” communication data transferring between server and the client will not be encrypted. It is possible that malevolent actors can intercept the communication and make modifications to the data, so it’s considered as “insecure communication”.
Where in “https” communication, SSL certificates will be used to secure the communication. SSL certificates are used to create an encrypted channel between client and the server. Transmission of such data like credit card information, login credentials or any other sensitive information will be encrypted to prevent eavesdropping.
How does Heartbleed work?
To understand this better, let me explain another component of TLS/SSL protocol, which is called “heartbeat“. During the secured communication between two machines, to keep the connection alive even when the user is not downloading or uploading any content, there will be an encrypted packet transfer that takes place occasionally, it's called as the heartbeat request. The receiving machine will send back the exact same data to acknowledge that the connection is still alive.
While performing a heartbeat request – response operation, it contains the packet length also in the request. So for example, request says “here is some 60kb request”, machine allocates 60kb memory first and writes the data to it and then reads the data from the same allocation to send it back to requester.
OpenSSL implemented this functionality without validating the packet size is the same as it claimed to be. Because of this, let’s say a request claims the size of the packet is 50kb and the actual size of the packet is 25kb only, in this scenario the memory allocation will be happening on the size which the packet is claimed (which is 50kb) and while returning it back, entire 50kb will be returned where the actual packet data is only 25kb.
This is the crucial part of this process, machines persist the memory buffer after it’s done using it also. This buffer is supposed to be replaced with the new content when it’s used again, but during the above mentioned scenario an additional 25kb data buffer of data which was stored earlier in that allocation block will be sent back to the requester. This data could be anything, it might be some part of scrabbled data which is not useful at all or it can be a SSL private key which can help decrypt the communication also.
The impact
About 17% of the SSL servers got affected due to this vulnerability. CVE-2014-0160 got added to the CVE database and more detailed study has been given to this issue. From those researches, it got identified that OpenSSL 1.0.1 through 1.0.1f (inclusive) were vulnerable. An attack on Community Health Systems that stole patient data was blamed on Heartbleed. A fixed version of OpenSSL was released on 7 April 2014, on the same day Heartbleed was publicly disclosed.
Behind the scenes
Smallest part of this story can traced into a single line of code which made this impact, which was
memcpy(bp, pl, payload);
Where memcpy() is the command that copies data. bp is the place it’s copying it to, pl is where it’s being copied from, and payload is the length of the data being copied. The missing part was to check if the amount of data in pl is equal to the value given of payload.
Fix has been released on the same day the issue disclosed and we can now patch this by updated the OpenSSL library to the latest release version. Fix for the issue as follows,
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->relent)
return 0;
/* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0;
/* silently discard per RFC 6520 sec. 4 */
pl = p;
First part of the code checks for the payload size is zero and the second part checks for the payload size is same as it claims to be.
Conclusion
As the title of this article says, small things can make an impact on a large scale. Security is not something to be taken as a “good to have” feature, it should be a “must to have” component for any successful organization. Also specific to this particular topic, if you find any of your servers running on this vulnerable version of OpenSSL, along with patching the same, try to update your SSL certificates for a safer side since you never know whether this machine has been breached or not.
Comments
Post a Comment