Security and Risk Management Strategies Blog

Still Can’t Win the Core Wars: A Report from Black Hat

Blogger: Dan Blum

At Black Hat DC 2009 Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab (ITL) presented “Attacking Intel Trusted Execution Technology (TXT).”  The authors claim to have:

• Imperiled the notion that Xen hypervisor (or any program) can bootstrap itself securely on a already-running computer by establishing a dynamic root of trust measurement (DRTM) using the Trusted Platform Module (TPM)
• Hacked the BIOS System Management Mode (SMM), demonstrating that attackers are just as capable of moving “down the stack” as “up the stack”
• Left Intel and/or other vendors with a major homework assignment to overcome design problems in the TXT

If valid, the Wojtczuk and Rutkowska exploits once again demonstrate the fallibility of software-on-software defenses, concerning which I previously posted Can’t Win the Core Wars. That post was about Black Hat 2008 exploits that demonstrate limitations in Data Execution Prevention (DEP) and related protections. This week’s new Black Hat exploits deal additional blows to the defensive team.
ITL’s presentation gave some background on what parts of the TXT are broken, how it was done, and what remains intact. First of all, understand that the TPM has a set of PCR registers that can hold hash values of critical system software modules. As the computer boots, first the BIOS ROM, then the BIOS PCI FLASH, OS boot loaders, and OS kernel load up in succession; the hash of each component’s in-memory bits is checked against the PCR values before continuing to the next. At the end of the process, if each component checks out, you have what’s called a static root of trust measurement (SRTM).

The good news is that ITL’s exploits do not affect SRTM. The bad news is that SRTM isn’t very scalable.  It takes a lot of software to get a general purpose computer going, and even more if one wants to initialize a hypervisor on top of the OS and then yet another OS inside of a virtual machine. SRTM requires initializaing PCR registers with the information to measure every possible piece of code that might be executed since the system boot.

To address SRTM’s scalability issues, Intel’s TXT includes a dynamic root of trust (DRTM) capability. DRTM uses an instruction called “SENTER” (AMD has a similar one called “SKINIT”) to extend a PCR register with the hash of a program to be loaded after the computer has booted.  For example, an initialization program could issue SENTER with the hash of a virtual machine monitor (VMM), load the VMM, and only activate it after the PCR attestation checks out. DRTM is also called “late launch,” and it is intended to transfer a system from an unknown/untrusted state to a known/measured or trusted state. This is a wonderful widget to have for dealing with unmanaged computers belonging to home users, consultants, customers, etc.

But DRTM can be attacked through the System Management Mode (SMM) code, which as part of BIOS is more privileged than OS kernels (ring 0) and hypervisors (ring -1). Think of the SMM as “ring -2.” SMM is loaded before late launch. It can, so to speak, eat your launch, heh. TXT does not repeat the SMM attestation after boot time, and ITL’s research suggests that attestation of running code is not reliable in any case.

Wojtczuk and Rutkowska went on with an entertaining description of their dialogue with Intel. Intel claims that exploiting SMM is hard, but ITL makes it look easy.  Apparently, ITL has broken SMM with multiple attacks, including one with a soldering iron to replace a chip on the motherboard. But the software attacks are easier, and there are multiple SMM bugs. Intel has been informed of these bugs and patched them, but then ITL found new bugs.

Apparently, SMM is large and complex because it must interact with many complex computer components. It must be tuned to each new motherboard and changes often. As such, SMM is a difficult program to harden, validate, and trust. When I asked an Intel representative about the SMM hack, he called it an “industry-wide problem” and said Intel had reached out to CERT to help coordinate repairs.
ITL says Intel’s solution to the DRTM TXT attack will be an SMM Transfer Monitor (STM). As best as I can understand it, STM will virtualize the BIOS so that it can be rebooted during a late launch. ITL said Intel argued persuasively that it could do a better job of protecting STM because it would be smaller and simpler than SMM. But STM does not exist yet, so we must stay tuned.

Editor comment: Don’t you love it when the vendor’s fix to an exploit adds another layer of complexity? They always seem to make software more complex, and then tell us it’s more secure. But at least most of the time, it’s not.

On to the bottom line: Very few, if any, organizations  are using DRTM in any way, shape, or form. However, system management mode (SMM) and BIOS are ubiquitous and exploits against them open a worrisome new front for rootkits and weaken the value proposition for hypervisors. ITL is giving Intel more time for patches before releasing the actual exploits, so it’s too early to tell how effective the countermeasures will be and how many rootkits will crop up in the wild. In the short term, make sure you’re prepared to patch SMM on existing systems and that anti-rootkit defenses cover SMM. In the long term, take vendor claims of DRTM with a large grain of salt.

Have CrackBerry, Will Travel

Blogger: Dan Blum

It is no surprise for us to hear loose lips flapping in India about a capability to decrypt Blackberry and other carrier traffic.

After all, we’ve done basic threat analysis for years and it was only months ago that I was brought into a company-wide CISO meeting at a U.S. defense contractor to help them hash out their travel policy for mobile devices. Going into the meeting, I knew their policy restricted taking devices to a list of countries considered dangerous – but there was an exemption for BlackBerries.

Our research uncovered that BlackBerry is pretty secure in most respects. It has transport encryption along with optional password protection, remote kill, disk encryption, and S/MIME encryption. Viruses have not flourished on this functionally limited and closed platform. Few if any third party add on programs are required for additional protection. Nonetheless, I went into the meeting prepared to talk with the CISOs about the risks and security limitations of life on BlackBerry.

Was the BlackBerry exemption reasonable? At the time, BlackBerry transport encryption was not known to have been broken (to be fair, the article listed above still qualifies as rumor, not certainty of breakage). However, I pointed out that it is dangerous to assume well-equipped attackers like military or intelligence organizations can’t crack transport encryption. And even if they haven’t cracked the BlackBerry network and whole disk encryption features, sophisticated adversaries have other attack paths. Check out Neal Stephenson’s excellent book Cryptonomicon for a description of how a talented adversary might “see” your keystrokes and screen images through a motel room wall, for example.

If one of your employees – such as a key scientist, project manager, or executive – is targeted for surveillance and is carrying sensitive data through certain countries, one could argue that he or she had better undergo serious counter-intelligence training.  Learn to spot and shake tails, sneak into dark alleys for that BlackBerry fix. Learn to paper the closet with layers of aluminum foil and send messages in the dark. Defend that BlackBerry with encryption, long passphrases, and kung fu. But unless James Bond is running your company, I doubt this is what your executives have in mind for the next business trip!

Assuming your organization’s lower level employees are like needles in a haystack and won’t be bothered could be an exercise in wishful thinking. It is always possible that nation states are monitoring some or all of the airwaves. Not so long ago the NSA had a massive a covert surveillance program in place. Years before the government was reportedly snarfing up terabytes of emails and crunching them through a program called Carnivore. And of course, selective monitoring of people on watch lists continues on a large scale. This is just the surveillance we know about in the U.S. We suspect there’s more behind the scenes and especially in countries such as China. Even if you train your non-specifically-targeted low level employees to write and speak in search-keyword-free code, the carnivore programs of the world are pretty good at sniffing out those interesting needles – such as descriptions of your business plans, manufacturing processes, and trade secrets.

Sound paranoid? I admit that I don’t know what the probabilities of being targeted or monitored are – just that it can happen. It’s the height of arrogance to believe that a nation state can’t get your information if they’ve targeted it and you’re within their borders. And it’s dangerous to rely on security by obscurity when medium or high consequence information must be protected.

What can be done? If key personnel can't dispense with the BlackBerry (or any other email device) during international travel to those countries where information may be most at risk, they (the users) should limit communications to what they’d feel comfortable uttering over a potentially-monitored telephone call. Controlling incoming communications – messages sent by others – is a harder problem. Until data loss prevention (DLP) products become more contextually sensitive about the travel issues, it may be best not to synchronize the BlackBerry with the overseas user’s home mailbox. Instead, have the user give out a temporary address for the BlackBerry and warn senders to be discreet.

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.’

Patch-reboot-repeat

Blogger: Trent Henry

I was updating a system at home last weekend, and I crossed paths with one of my big pet peeves: incessant need to reboot after patching.

As my system was restarting, I thought to myself, “Man, reboots are required more often than not. Is it always kernel-level software that’s getting updated?” As I looked at the patch manifest, it seemed to me that many of the pieces of software should be running in user space, and hence a post-patch process restart should suffice, rather than a reboot. Fortunately, it wasn’t a server system (not that my home uptime requirements are all that rigorous anyway), but it still bugged me, and not just because of inconvenience.

Before proceeding, I have an admission to make. When I used to code Sun Unix boxes back in the day, I used Sun’s packaging system for installation and de-installation of my software. The installation script API used a return code to determine whether a system reboot was required after software install. Because my package installed new services, a reboot was the safest (and, ahem, easiest) way to ensure the server would be running after installation. But I have to sheepishly admit that a restart wasn’t really required. There was an element of laziness in my choice: I wasn’t sure about all the side effects of the install, and I wanted a clean slate; hence, reboot.

Wearing a security hat, though, this laziness really worries me. If developers routinely require a reboot “just to be safe,” I’m concerned that they haven’t fully considered the effects of their code changes. Or, even more alarming, perhaps reboots are required because so much software is running in a privileged process space or otherwise can’t simply be restarted without system disruption. This implicates the entire OS architecture as insufficiently layered, because way too much stuff is running at elevated levels, rather than operating as user-mode services with least privilege.

Whichever the answer, it’s pretty annoying – especially to the IT server managers who try to keep uptime at a high level.

I think we can do better.

How much is enough in an endpoint protection suite?

Blogger: Dan Blum

I was reviewing a product profile for a small anti-malware vendor with our analyst team, and received the following question:

“In the analysis of the product, you only mention its lack of host intrusion prevention software (HIPS) as a gap, but not its lack of a vulnerability management product. What components need to be part of core endpoint security functionality?”

At this point I’m evaluating endpoint anti-malware suites as follows: While customers may not deploy all these features, the vendor should be able to offer anti-virus, anti-spyware, web threat protection, mailbox/mail scan, system firewall, NIPS, HIPS, NAC, and application control on the endpoint – all with unified administrator-minimizing management, broad platform support, easy migration from previous releases, good end user experience, modularity, affordable pricing and good industry test results.

Symantec and McAfee, as the market leaders, provide benchmarks against which other vendors in the anti-malware space can be compared. The Big Two are broadening “endpoint protection” to include data leakage protection (DLP) and host encryption in their product lines. But it will take some time for McAfee and even longer for Symantec to move the acquired products into the single agent/single console architecture they both tout for their endpoint anti-malware components. Both also have host-based vulnerability management (scanning, remediation, patching), but only McAfee has integrated vulnerability management with its ePO manager software. Both vendors will price vulnerability management, DLP, and encryption separately from anti-malware for the indefinite future.

The real benchmark is: What do the customers want? In my experience large enterprise customers are generally on a vendor diet, trying to get from tens of security vendors to lower numbers, but not to one.

I don’t see great urgency on customers’ part to subsume endpoint anti-malware into a larger endpoint protection suite. However, the vendor diet (consolidation) might lead some to choose the larger suite vendor over the niche vendor if the large vendor is equal or close to equal in price, performance, and functionality.

Smaller vendors such as Trend Micro, Kaspersky, Sophos or Panda Software that are chasing Symantec and McAfee market share in the anti-malware races, might have a fairly complete anti-malware suite but lack any or all of DLP, host encryption, and vulnerability management. But because Symantec and McAfee haven’t yet integrated anti-malware with all their other endpoint security functions (let alone merged the pricing), I don’t consider the lack of offerings beyond anti-malware a weakness for the smaller vendors. But it is something to keep an eye on, as the security suites have a way of expanding.