‘Use After Free’ is the name given to security vulnerabilities that occur because of a problem with the way an application is managing its memory. When one part of a program attempts to use some memory that another part of the program has released because it is no longer needed the application may crash, produce unexpected results, or even be tricked into executing new code supplied by an attacker.
How Memory is Managed
Memory is managed in different ways based on the programming language that an application has been written in. Some languages (such as Java) attempt to manage the memory on the programmer’s behalf, whereas others (such as C and C++) require the programmer to manage the memory allocation directly.
In the C programming language, the instruction malloc() is used to allocate a requested size of memory space for use by the program. Every variable or data structure used by the program will need a malloc() call to allocate some memory of the required size. The malloc() function returns a pointer or signpost that points to the address of the start of the allocated portion of memory. When the program needs to read or write to that data in memory it uses the pointer. When the program is finished using the data, it can release the memory using the function free().
The free() function tells the memory manager that the allocate memory block is no longer required and can be reallocated in full or in part when requested by another malloc() request.
It is important to note that free() simply marks the memory block as free and available for use. It does not wipe the memory block clear of any data that was stored in it, nor does it release or clean up the pointer that the program had been using to reference that memory block. A pointer which is referencing a memory block that has been released using free() is known as a dangling pointer.
How Use After Free vulnerabilities occur
There is no concept of security that protects the contents of a given memory block to only be used by certain pointers – all the memory space for a program is available to be used by any pointer in any part of that same program.
Now if the program again makes use of the dangling pointer to a freed memory block it will still have access to whatever is stored in that location – and if that memory had subsequently been reallocated to a part of the program that is managing sensitive data that data could be accidentally changed or disclosed. For example, if the memory block that initially contained a welcome message to display on the main menu was reallocated so that it now contains the username and password of the user, that password would get displayed on the main menu instead of the welcome message if the pointer was accidentally re-used.
Use After Free vulnerabilities are always the result of a mistake in the application code – a malicious attacker cannot create a new use after free vulnerability in your system – but they can make use of the vulnerability after it is discovered.
For example in March 2022, Apple released iOS 15.4 which included a fix for a use after free vulnerability (CVE-2022-22667) in the GPU drivers that could allow an application to execute arbitrary code with kernel privileges. In January WordPress patched a use after free vulnerability (CVE-2022-21661) which could be exploited to achieve SQL injection attacks.
An attacker could exploit a Use After Free vulnerability to pass arbitrary malicious code (or a reference to it) into an application and then use the dangling pointer to navigate to the start of the arbitrary code and so execute it.
How to defend against Use After Free vulnerabilities
Use After Free vulnerabilities are caused by coding errors and so once discovered the main defence is to install an updated version of the application which has the vulnerability fixed. Web browsers appear to be particularly prone to this type of vulnerability so ensure you have automatic updates enabled on all your web browsers.
For developers of in-house applications, source code analysis tools can help to locate use after free and other common coding mistakes that lead to security vulnerabilities.
Application penetration testing will also help you identify these and other vulnerabilities within your applications.
Further Reading
Use After Free in the Common Weakness Enumeration
“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”
Aim Ltd Chief Technology Officer (CTO)