Our Blog

Why “Memory Management” Bugs Deserve Your Absolute Attention!

Aug 15, 2019 Shin-Ming Liu

In the context of IT for business, customer data is the center of focus. Hence, protecting that customer data is naturally the most crucial responsibility for any IT professional. Many countries or regions have established legal requirements for data to be encrypted at rest and during the motion. This leads many people to feel the data is secured if the IT systems are conforming to the law. The reality is that data is still being decrypted during CPU operations. Consequently, passwords and keys are required to enable the data encryption and decryption. On top of this, data administrators will need the ability to recover data when users lose their password or key. Data during the decrypted state for computation and all the transitions between the decrypted state and the encrypted state are vulnerable to hostile exploitation.

Let’s focus of on the data during the decrypted state. The user passwords or keys are among the most critical to protect. At certain specific points in the time, this data will be decrypted and stored in a data buffer in the computer system. In principle, all software defines their own buffer management mechanism include the protocol to allocate and deallocate buffers that store data. As we all know software applications will be created and modified by various software engineers from different organization at different times of the software life cycle. Bugs get introduced as the natural consequence and can have serious impact on memory management.

One example of a memory management bug is the recent announcement from Google recommending users to update Chrome (CVE-2019-5786). It is a ‘use after free’ (UAF) error that causes user’s computer files to be leaked. This memory management problem occurs in relatively complicated control flows and across procedural boundaries. Above all, the procedure that introduced the exploitable bug is an open source API. Simply speaking, the bug is caused by a specific window of time, during which the exploitation code could get hold of the pointer to sensitive data. Knowing this window of opportunity is a non-trial task.

This brings up another interesting point about open source software. Open source has facilitated the explosive growth of internet and mobile software in the past 20 years. It brought great value to the software industry but not without a downside. It gives hackers the opportunity to study the software and develop sophisticated techniques to exploit the software.

It is the use of static code analysis tools that provide the capability of analyzing sophisticated software systems at a source code level to detect issues that are vulnerable to exploitation. Many static analysis tools only work at a pattern level whereas advanced tools use analysis engines on top of the compiler optimization frame that has delivered highly optimized code for high performance computing.

At Xcalibyte, we have developed a method to model the life cycle of a data buffer from the time of allocation to the time of deallocation, and beyond. With the precise memory object model, we are able to identify operations that reference the data after the buffer has been deallocated.

Although we can detect software bugs, developers are ultimately responsible for writing robust code. A good practice I would recommend is to clear out the buffer after the buffer is deallocated. Yes, some open source compilers can do it with an command line option. However, it is crucial to bear in mind, a compiler can only recognize the standard memory allocation functions. It won’t do anything, if you have your own customized memory allocation functions. Think ‘quality first’ and think ‘security-by-design’!