Can’t Win the Core Wars

Blogger: Dan Blum

Core Wars is a game in which two or more battle programs compete for the control of a simulated computer. The battle programs are written in an assembly language. The object of the game is to terminate the opposing program(s), generally by overwriting them, leaving your program in control.

Core Wars also go on in real life. The early 2000s saw a number of notorious worm programs (Nimbda, Code Red, Slammer, Blaster) performing buffer overflow and other memory-overwrite attacks to seize control of Windows computers and spread themselves all over the Internet. Today, the game goes on, and has in fact become a livelihood for burgeoning numbers of cybercriminals.

Facing the attackers are Windows, IE, Firefox, and other third party security programs on the defense. One defensive strategy is to harden legitimate code so that it is more difficult for attackers to overwrite memory and seize control. When Vista shipped, many thought that Microsoft may have won some rounds for the good guys with low level memory-based protections: data execution prevention (DEP), address space layout randomization (ASLR), and the /GS compiler switch for improved stack protection as well as other code integrity checks.

However, at Black Hat USA 2008, Alexander Sotirov and Mark Dowd released the “Bypassing Browser Memory Protections” paper, which announced new breakthroughs against DEP, ASLR, and /GS. In hindsight, the industry should have seen the breakthroughs as more inevitable than we did, and it is clear that we need to do more on defense to keep attackers at bay. But first it is important to clarify what Sotirov/Dowd’s research means, for there has been much confusion in the press, with some saying the sky is falling and others saying its nothing new. The truth lies somewhere in between.

First, some background on the main low level memory protections that can be used with Windows Vista, Windows Server 2008, and (in some cases) XP:

• /GS generates code causing functions to check for overwrite of return addresses on the stack, as might occur during a buffer overflow attack
• SAFESEH triggers validation of pointers to exception handler routines, trying to prevent them from being overwritten (for example, with pointers to exploit code)
• DEP prevents the execution of code in memory pages marked non-executable; this is designed to stop attack code written to the stack or heap from being executed
• ASLR randomizes the addresses where objects are loaded in the virtual address space of a given process; without knowing memory locations in advance, exploits are more difficult to develop

These protections are implemented through a combination of compile/link options, compiled code, OS program loader options, and (in the case of DEP) hardware CPU features.

Sotirov/Dowd described attacks against the low level protection technologies starting with exploit code aimed at the Internet Explorer 7 browser, but the paper also wrote extensively on reusable types of exploits possibly applicable to other Windows programs. The paper claims the authors have demonstrated the following types of exploits against memory:

• From Javascript - spray the Internet Explorer heap with 100 MB of shellcode to bypass ASLR if it is enabled; jump into the shellcode by overwriting the return stack pointer. If the stack is protected by /GS, overwrite an exception handler record and trigger an exception.
• Flash code reuse – if both DEP and ASLR are enabled (in Vista or Windows Server 2008), bypass ASLR by exploiting DLLs which are loaded at a fixed address in the browser address space. Many popular browser plugins, including the latest versions of Flash, are not compatible with ASLR. The exploit bypasses DEP by creating stack frames in a way that causes Windows memory management routines to mark selected heap pages (where shellcode has been written) as executable.
• Java Runtime Environment (JRE) plug-in to IE - Spray the Java heap with shellcode until an out of memory error is caused (after over-writing the exception handler to point into the heap). Memory pages in the Java heap are already marked executable, for compatibility with certain programs.
• Exploit .NET executable binaries that implement some of the UI control functions. It is also possible to spray large copies, or multiple copies of the .NET binaries into the address space so as to defeat the randomization process when ASLR is enabled.

My two big takeaways after reading Sotirov/Dowd are these:

1. We’re not winning the core wars: Low level memory protections in Windows (while useful) were not as decisive as we hoped. While over time more programs will use /GS, DEP, SAFESEH, and ASLR – making these mechanisms more effective in combination with each other– there will still be room for exploits because there are still too many holes in the OS architecture.
2. Don’t put too much trust in browsers: As Burton Group’s Ramon Krikken put it in his “browser is sick” post last week, browsers suffer from bloat and compatibility problems – just like the underlying OS. Sotirov/Dowd cite the degree to which the browser state can be controlled by the attacker, and the extensible plugin architecture of modern browsers as two reasons why they are such juicy targets.

Where do we go from here? For now, the defensive team can’t win the core wars, but when we own the computers under attack we can cheat; we can make the playing field less favorable to attackers.

As a case in point, Sotirov/Dowd wrote that their vulnerability testing all started by exploiting the ANI vulnerability in the Windows animated cursor functionality to get a toehold on the system.

Now I ask: what is the business purpose of an animated cursor? Get rid of all that nonsense and lock down systems so that users have less privilege, fewer programs, and less extensibility.

But the ultimate solution, if there is one, will take more than lock down. First of all, lock down isn’t always possible in business environments. Also, businesses must interact not only with the managed systems they control, but with many unmanaged ones as well.

As a longer term solution, it would be great if OS vendors did more memory segmentation, reduced kernel sizes, and implemented sensible ring transition architectures as well as system integrity requirements for privileged applications. Virtualization - providing memory segmentation between slimmed-down, locked-down virtual machines performing specific tasks – may be the next great hope to help us fare better in the core wars. For an even more radical solution to the endless woes of general purpose OSs see the Slidecast - Security Architecture in a Deperimeterized World.