Double free

Double free is a memory management flaw that occurs when a program releases the same memory block twice using the free() or delete function. Memory unsafe languages such as C++ are particularly prone to this vulnerability.

Calling the free() function with the same argument more than once can result in corrupted memory management data structures. This can lead to all kinds of other unexpected behavior, which could include arbitrary code execution and program crashes.

In this lesson, you will learn about vulnerabilities stemming from double free and how to protect your applications against them. We will step into the shoes of a data analyst who happens to stumble upon a double free bug in the wild. After this scenario, we will go over the vulnerable code, the impact, and some possible mitigations.

Let's break down what happened in the story above.

We were sending requests to the /action endpoint to perform log analysis. At some point, we sent a concatenated version of two actions, and the server seemed to have crashed.

A simplified version of the backend code from Loggerr is the following:

The endpoint receives a string parameter, which holds the action the user wants to execute on the log file. If analyze_trends is present in the action, then the analyzeTrends function will be called, and its response will be returned with activity_heatmap and error_rate.

At first glance, there seems to be nothing particularly wrong with this code. The log_data variable is freed after it has been used by an action. But notice how there are multiple free(log_data) calls. Somehow we were able to trigger multiple of those by supplying an action string that contained two or more action names.

We were able to trigger code behavior that the developer had not foreseen. Because the action variable would contain multiple different action names, each of those action.find() calls would be true, and the application would perform multiple actions, ending with multiple free() calls on log_data.

Double freeing memory can introduce significant risks. When memory is released using free(), the associated block becomes available for other allocations within the program. Freeing the same memory block again could lead to the corruption of currently allocated memory or of the internal structures used by the memory management system.

From a security perspective, double free vulnerabilities can be quite concerning. Attackers with knowledge of such vulnerabilities might exploit them to overwrite function pointers, return addresses, or other crucial data. Successfully manipulating these structures can grant the attacker the ability to run arbitrary code or elevate privileges within the application or system.

In our situation with Loggerr, the crash occurred because of the underlying memory management mechanisms in place. Modern glibc (GNU C Library) contains built-in checks that detect anomalies like double frees. Upon detection, instead of proceeding with potentially corrupted memory operations, the system halts, ensuring that the application's state remains uncompromised.

Preventing a double free vulnerability can be as simple as making sure you don’t double free a memory block. But this is easier said than done, as demonstrated in the scenario above.

The backend code of Loggerr can be changed to the following:

The free(log_data) call has been moved to the end of the function, making sure that it's only called once. Additionally, the separate if statements have been combined into if else statements, to counter the possibility of executing multiple actions.

Apart from preventing double free, you can also mitigate it in several ways. As you might have noticed, the code above sets the log_data variable to NULL after freeing the memory it points to. This is a safeguard against dangling pointer pitfalls.

When you access a dangling pointer after it has been freed, there's a risk of reading or modifying unintended sections of memory. However, if you try to access a nullified pointer, most systems will immediately crash. This crash provides instant feedback about the problem, making debugging more straightforward and exploitation practically impossible.

In addition to the code safeguards we've discussed, we also have underlying system protections at play. Remember when we ran into that crash with Loggerr? That intervention came courtesy of the glibc (GNU C Library). Modern glibc versions have built-in checks specifically designed to catch issues like double frees. When they detect such anomalies, they immediately intervene, stopping potential memory corruption in its tracks.

Learn more about double free with some additional resources

• An OWASP vulnerability description about double free
• CWE-415 which is bound to double free vulnerability
• Examples on double free by Microsoft