SHARE

How to Reduce Use-After-Free Memory Risk

Look at any recent security update from Microsoft, Google or Mozilla and you will find use-after-free memory errors. These vulnerabilities enable attackers to take advantage of allocated memory after it has already been used. Attackers can potentially leverage that memory space to execute arbitrary code. “We’re seeing more use-after-free memory attacks than we ever have […]

Written By

Sean Michael Kerner

Jul 14, 2014

eSecurity Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Look at any recent security update from Microsoft, Google or Mozilla and you will find use-after-free memory errors. These vulnerabilities enable attackers to take advantage of allocated memory after it has already been used. Attackers can potentially leverage that memory space to execute arbitrary code.

“We’re seeing more use-after-free memory attacks than we ever have before,” Karl Sigler, manager, SpiderLabs Threat Intelligence at Trustwave, told eSecurity Planet.

One reason use-after-free flaws are increasing is the evolution of attacker methods. Sigler noted that attackers are adapting to operating system-level protections, including Data Execution Protection (DEP) and Address Space Layout Randomization (ASLR), that help prevent standard memory buffer overflow attacks.

Use-after-free errors can easily be found in application software with widely available tools including the open-source Address Sanitizer program. Trustwave uses a variety of such tools, Sigler noted.

Not Easy to Exploit

Just because a researcher is able to find a use-after-free vulnerability doesn’t necessarily mean that the vulnerability is easily exploitable in the client-side application.

“It can take some ninja-fu, it’s not brain dead easy,” Sigler said.

The end result of a use-after-free vulnerability can vary for exploitation. In some cases, it can lead to a denial-of-service (DoS) condition and in other cases a security researcher might be able to run executable code.

“It does take a lot of knowledge and sophistication,” Sigler said. “But of course it only takes one researcher to make the discovery, and then everyone else can just copy the research.”

Increasingly the method used by researchers to make a vulnerability exploitable is a technique known as return-oriented programming (ROP).

“ROP has become the method of getting executable code onto the stack,” Stigler said. “ROP chains hop through memory looking for executable pieces of code they can chain through and eventually find a method of getting to run.”

Limiting Use-After-Free Memory Risks

There are a number of things organizations can do to limit risk. A Web application firewall (WAF) can be used in some cases to provide a network-layer protection against use-after-free vulnerability exploitation. Sigler noted, however, that there is no one single method that can catch every type of use-after-free vulnerability on a WAF.

Microsoft recommends the use of its Enhanced Mitigation Experience Toolkit (EMET) as a technology to help limit the risk of zero-day exploits.

“EMET really does a good job,” Sigler said. “It’s not a silver bullet, but so far it has a pretty darn good track record.”

Application developers should strive to build better security into their apps. Sigler suggests that code auditing before code goes into production is an obvious best practice that developers should embrace.

“Developers should understand what their code is actually using in memory,” Sigler said. “If the program is freeing memory and still flagging it as being able to be used, the program should be able to control what the memory is used for. That would eliminate a lot of the vulnerabilities that attackers have.”

Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.