Security and Risk Management Strategies Blog

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.

The web browser is sick … but where’s the cure?

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

Past, Present and Future Security Initiatives on Exhibit at Microsoft TechEd

Blogger: Dan Blum

One of our service directors likes to quote William Gibson: “The future is here, it’s just unevenly distributed.”

At Microsoft’s Server and Tools Business (STB) Analyst and Tech Ed conferences last week, I saw a vendor and a user community living in the past, present and future with many unevenly distributed capabilities.

In a session on identity management strategy, for example, Microsoft discussed a variety of initiatives. These range from Card Space (futuristic implementation of user-centric Information Card specifications) to ADFS (present day enterprise federation support, though unfortunately lacking full SAML capabilities) to self-service password reset exposed through Office (decidedly backward-looking as this functionality has been available from many vendors through browsers for many years).

In another session on rights management and SharePoint, Microsoft highlighted the opportunity to configure SharePoint libraries to automatically apply Active Directory Rights Management Services protections on downloaded documents. Digital rights management (DRM) is controversial and no strong guarantor of confidentiality. Nonetheless, it is a  way to put futuristic self-protecting wrappers on content so as to prevent its accidental leakage or misuse by honest, cooperative users. Because it’s not something that can resist certain types of malicious attackers, many security professionals look down their noses at rights management. Nonetheless, preventing accidental misuse of enterprise information is a big part of the space. It was clear from the number of people in the room asking intelligent questions suggesting realistic expectations that customers see potential value for this technology.

Finally, I was impressed by a presentation on IPSec, PKI and NAP by a Brazilian university IT manager named Rodrigo Imaginario. Starting three years ago, the university combined its student and administrative networks into a single network. Yet servers running ERP and containing administrative content (such as grading information) need to be protected from a subset of students going through their hacking stage. Imaginario implemented a logical security zoning overlay on top of the network using IPSEC in Windows. In the restricted zone, servers only accept connections from Kerberos-authenticated IPSEC clients in the administrative domain. Today, the authentication is being upgraded to use PKI for secure, all campus wireless networking. Imaginario indicated the university took the Windows IPSEC route approach because no additional software had to be purchased. Configuration was difficult, he said, but will get easier with Windows Server 2008. This sounds like an idea whose time has come.