If you’re in software development, you may know dynamic memory allocation and management can be a mixed bag. Although memory management within modern software has improved by leaps and bounds, the allocation and release of system memory resources can vary greatly.
When lacking in resources, attackers can take control of your application using vulnerabilities such as the Use After Free (UAF) vulnerability.
What is use after free vulnerability?
Use after free is a vulnerability scenario resulting from inefficient memory management while developing software applications. In simple terms, it occurs when modern programming languages enable programmers to allocate memory dynamically at run time.
How do threat actors do this? First, they use a programming construct called pointers to ‘point’ to a block of memory in a swath of freely available memory blocks provided by the operating system – this is known as the ‘heap.’
Then, programmers set the pointers to specific allocated memory to hold data structures, free the allocated memory, and reset the pointers once the work is complete.
As the code base evolves, there can be instances where due diligence in allocating and freeing up memory is not followed, especially when the pointer is not reset. The memory it was pointing to might get reassigned to a different application.
Since the previously assigned memory block is suddenly freed for other usages, but the pointer is still used to point to that block of memory, it becomes a ‘dangling’ pointer. That’s when the scenario classifies as use after free. So then, how does a use after free scenario make your code vulnerable?
How does use after free vulnerability work?
Suppose you were trying to personalize your shopping application to fetch and show customer shipping addresses once they log in. In a UAF scenario, the application code pointed to a memory block holding the address information data structure. But as the pointer was not reset to null, it still points to the same block, which might now store payment information or other sensitive data from a different application.
If an experienced threat actor can investigate how the application is written, they’d be able to intercept and access this data for malicious purposes. They might also choose to use the memory block if it hasn’t been assigned to any program to host a piece of malicious code. That way, the unsuspecting program still pointing to it would run that code and give them access to sensitive parts of the application data.
Key examples of use after free vulnerability
Not all bad actors can understand and exploit UAF vulnerabilities since a deep understanding of the particular application is required. Unfortunately, the scenario described above has become rampant, especially in the web browser application space.
However, once such vulnerabilities are discovered, the only way to thwart exploitative usage is to patch these applications to fix the issues immediately. As a result, many large-scale OS and web browser platforms like Apple and WordPress regularly patch their systems to fix UAF vulnerability issues.
Impact of use after free vulnerability
Bad actors have been known to employ a wide range of UAF impact scenarios. The list below is far from exhaustive but provides a range of typical techniques reported recently for UAF-based vulnerabilities in large software applications.
Causing memory overflow issues and crashes
Accessing sensitive data with code and SQL insertions
Execute code with elevated privileges to access user data
How to mitigate use after free vulnerabilities
Employ good coding and testing practices
Robust memory debugging tools and a comprehensive penetration testing framework should set your development teams up for securing their code from UAF vulnerabilities.
Patch quickly and patch often
The primary way to thwart attackers is to update your apps and servers with the latest updates. If you can automate your patching activities across your IT infrastructure, you’ll have a better shot at safeguarding your applications.
Enforce strong security controls
Stop bad actors from accessing your IT infrastructure by setting up strong access policies and authentication methods like multi-factor authentication (MFA).
Use after free vulnerabilities: A stitch in time saves nine
We all know the perfect code base doesn’t exist. But you can get closer to that dream by working with your development team to instill diligent programming and testing practices.
If you can augment this diligence with an automated approach to patching and keeping your IT infrastructure current, you can build a formidable defense for your ITOps team against UAF vulnerabilities within your applications.
