Larger implications of Heartbleed

I was looking at Heartbleed bug code and it appears that it is not a buffer overflow. Rather, the buffer is left unfilled and the receiver fooled. The receiver just echoes the data which the sender sends and thinking that the sender has sent more data, it reverts data from its own memory.

While most overflow checks will check if the input is more than the input size mentioned, do they also check if the input is less than the input size mentioned? It appears that some static code analysis tools — namely Frama-C – would have flagged some warning on some aspects of this bug but given that most people run such tools while really not setting all conditions meant to do a thorough check mainly due to time constraints (a thorough check takes more time for the tool to run), it would have been missed out in most likelihood. Also, the OpenSSL developers were not successful in detecting it.

This also gives rise to possibilities that this kind of bug might be present in other software. After all, this is a new kind of bug — memory containing possibly sensitive data was used due to lack of bound check and it is possible that similar bugs could be present elsewhere.

This would be worth investigating. In fact, a huge number of open-source software right from the Linux source, to other prevalent software such as Apache could be a good place to start with. Also, an equivalent analysis of binary code could be done on popular tools such as WhatsApp or Skype.

The Heartbleed bug is also a tragic commentary on the state of security in the industry today. Why don’t we yet have a fool-proof method that finds out such bugs before release? A recent post on the OpenSSL mailing list said that while companies are willing to fund for more features to be implemented, it is difficult to get funding for routine tasks.

Hopefully, a day will arise where we would have found all such bugs before the software is released.