{"id":1464,"date":"2014-04-09T16:07:34","date_gmt":"2014-04-09T14:07:34","guid":{"rendered":"http:\/\/cerezo.name\/blog\/?p=1464"},"modified":"2024-10-14T13:25:50","modified_gmt":"2024-10-14T11:25:50","slug":"preventing-more-heartbleeds","status":"publish","type":"post","link":"https:\/\/cerezo.name\/blog\/2014\/04\/09\/preventing-more-heartbleeds\/","title":{"rendered":"Preventing more Heartbleeds"},"content":{"rendered":"

It\u2019s all over the news: a vulnerability has been found on OpenSSL that leaks memory contents on server and clients. Named Heartbleed<\/a>, it has a very simple patch<\/a> and some informative posts have already been written about it (Troy Hunt<\/a>, Matthew Green<\/a>).<\/p>\n

What nobody is saying is that the real root cause is the lack of modern memory management in the C language: OpenSSL added a wrapper around malloc()<\/em> to manage memory in a more secure and efficient way, effectively bypassing some improvements that have been made in this area during a decade; specifically, it tries to improve the reuse of allocated memory by avoiding to free()<\/em> it. Now enter Heartbleed<\/a>: by a very simple bug (intentional or not), the attacker is able to retrieve chosen memory areas. What was the real use of that layer?<\/p>\n

Face it: it\u2019s a no-win situation. No matter how many ways these layers are going to be written, there will always be a chance for error. You can\u2019t have secure code in C.<\/p>\n

But re-writing and\/or throwing away thousands of security related programs written in C is no-brainer: the only way to securely run these programs is with the help of some memory debuggers techniques<\/a>, like those used by Insure++ or Rational Purify. For example, the next technical report contains a detailed analysis of some of these techniques that prevent these kind of vulnerabilities:<\/p>\n