Skip to main content

'Freezing' Software Could Kill Malware by Starvation

An ice cave in the Perito Moreno glacier in southern Argentina. Credit: Martin St-Amant/Creative Commons

(Image credit: An ice cave in the Perito Moreno glacier in southern Argentina. Credit: Martin St-Amant/Creative Commons)

BROOKLYN, NEW YORK — Future defenses against Windows malware may include changing the code of legitimate applications as they run, a security researcher explained at the Summercon 2015 hacker conference today (July 17). Collin Mulliner, a postdoctoral researcher at Northeastern University, said that he and a fellow researcher, Matthias Neugschwandtner of the Vienna University of Technology, devised a way to strip away unused code from the memory allocation of a running Windows program.

Getting rid of unused code thus "starves" potential malware by denying it the system resources it needs to operate, and also reduces the application's overall attack surface. The application being attacked gets only the code it needs to run, and nothing more.

MORE: Best Antivirus Software and Apps

Mulliner explained that most Windows applications are dependent on dozens, if not hundreds, of dynamic-link libraries (DLLs), modular packages of code provided by Microsoft for application support. However, because each DLL contains many related bits of code, an application will normally load much more code than it actually needs into running system memory, or RAM, when it accesses a DLL. Malware often uses that extra code for its own purposes when exploiting a flaw in the application.

Mulliner and Neugschwandtner's tool, which they've called CodeFreeze, analyzes exactly what an application needs and doesn't need from its DLLs. Then it overwrites the unnecessary DLL code in the application's running memory so that the code can't be exploited by malware.

To prevent malware from injecting malicious code as extra DLLs, CodeFreeze also "freezes" the running application's memory allocation so nothing can be added. Because CodeFreeze is packaged as a DLL itself, it adds very little system overhead to a running application. A live demonstration by Mulliner showed that Adobe Reader with CodeFreeze enabled took only a couple more seconds to open than it normally would have.

More than half of the Windows system code loaded by Reader was negated, yet the application ran just fine. A piece of malware Mulliner had created, which successfully exploited Reader before CodeFreeze was turned on, failed to work once the tool was activated.

And because the code modification is performed in running memory and not saved to disk, neither the application nor the DLLs it uses are permanently altered in any way. Mulliner said he and Neugschwandtner had gotten CodeFreeze to run well on 32-bit Windows 8.1, but had not yet tried it on 64-bit Windows 8.1.

Mulliner told Tom's Guide that the pair hoped to submit CodeFreeze to Microsoft's BlueHat Challenge for innovative security research. Ultimately, he said, Microsoft would have to implement CodeFreeze's methods and secure the cooperation of application developers for the solution to work completely.

Paul Wagenseil is a senior editor at Tom's Guide focused on security and gaming. Follow him at @snd_wagenseilFollow Tom's Guide at @tomsguide, on Facebook and on Google+.