Over the past decade exploitation techniques have been developed and refined to the point that very little expertise has been needed to successfully exploit software vulnerabilities.  These refinements have lowered the bar for attackers and drastically increased the probability that an attack will be successful.  This has led to the need for mitigation techniques that can prevent or otherwise reduce the reliability of a given exploitation technique.  In relation to one another, we can think about exploitation techniques as attempting to drive the probability of successful exploitation to 100%, whereas mitigation techniques attempt to drive the same probability to zero.  While probability gives us a nice measure for the effectiveness of a mitigation technique, it doesn't give us immediate insight into the specific problems being solved by mitigations or the techniques that are being used to solve those problems.

Understanding the problems that are solved by mitigations is what provided the motivation for the presentation I will be giving at BlueHat.  Many of the materials in this presentation were taken from my work with Leviathan Security Group and have been repurposed to focus on taking attendees on a journey through the technical evolution of the mitigation techniques developed by Microsoft.  This evolution is illustrated in terms of the problems each mitigation technique is attempting to solve, the methods used to solve them, and how well each mitigation has stood the test of time thus far.  The journey itself starts first with /GS and ends with a glimpse of the mitigation techniques we might expect to see in the future. 

So, in conjunction with the BlueHat team, I am pleased to announce that the SDL team will be organizing the sessions for the second day of the fall BlueHat conference. The BlueHat SDL sessions will be laser-focused on not just describing vulnerabilities but also solving them. Every attendee should leave every presentation with a clear idea of exactly what he or she needs to do to protect themselves from the threat that was discussed during the session.

The sessions will begin, appropriately, with the topic of secure design. Danny Dhillon of EMC and the SDL team’s own Adam Shostack will each present their organization’s approach to threat modeling. As a bonus, Adam will also be demonstrating the new SDL Threat Modeling tool that you might have heard about last week.

Next up is Matt Miller, a recent and very welcome addition to the Microsoft Security Science team. Matt has a fantastic presentation on the evolution of buffer overflow attacks and on the corresponding development of overflow mitigations. From there we will switch gears to look at some managed code implementation issues: iSEC Partners’ Scott Stender and Alex Vidergar will demonstrate coding techniques to mitigate elusive concurrency vulnerabilities in web applications.

At this point we will have covered the Design and Implementation phases of the SDL; where better to go from here than Verification? One of the most important activities in the Verification phase is fuzzing, and we have a trio of security experts from the Microsoft Security Science team to talk about it. Jason Shirk, Lars Opstad, and Dave Weinstein will answer three of the most common fuzzing questions: How should I fuzz? When have I fuzzed enough? And what do I do now that I’ve fuzzed?

Finally, we will wrap up the Verification phase talks with a return appearance to BlueHat by Stach & Liu’s Vinnie Liu. Vinnie will compare different approaches to security verification – static code analysis, blackbox analysis, and manual code review – and make recommendations as to when each approach is best used.

Even if you can’t make it in to BlueHat in person, you can still watch the sessions via streaming media on TechNet. Additionally, webcast interviews with the speakers – condensed “Cliff’s Notes” versions of their full presentations – will be posted on Channel 9. And we’ll be continuing the BlueHat tradition of inviting speakers and other industry notables to guest blog about their topics and the latest security trends. More information on all of these resources will be posted here when it becomes available.

Ten days before VMworld and VMware still can’t get good press. First their CEO, Diane Greene, gets ousted, then a high-profile licensing bug is found and now the Director of R&D, Richard Sarwal, leaves his $1.25 million salary after just 7 months. (Note to self: get into R&D) It will be interesting to take the pulse of the VMware community at the show and in person. And in the meantime, Microsoft Hyper-V comes out of the gate with customers already touting its benefits.

The hypervisor is the “new” operating system. If you didn’t think that before, take a look at Red Hat’s purchase of Qumranet for $107 million. With Qumranet, Red Hat gets KVM, described by CTO Brian Stevens as an extension to the Linux kernel that allows it to be used as a bare-metal hypervisor, running directly on the underlying hardware and hosting guest operating systems. But according to Brian Madden, the “press” around the purchase is all focusing on the not-so-interesting part. Along with KVM, the SolidICE product includes Spice, a remote display protocol for VDI.

I wonder if this will be like Symantec buying Altiris or Microsoft buying Softricity, where the portion that we care about sort of loses focus as The Borg concentrates on the parts of the acquired technology that are more relevant to them?

(I’m a sucker for quotes that reference The Borg)

Network World publishes “10 open source companies to watch”. On the list, Qumranet!

Also on the list: Kickfire, Marketcetera, Vyatta, Sonatype, Untangle, XAware, SnapLogic, Acquia and Openmoko. What’s best about the list: Matt Asay gives it a thumbs up.

The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

This essay previously appeared on Wired.com.

EDITED TO ADD (8/26): Matt Blaze has a good essay on the topic.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

Braving the Cold (Boot) – A Sneak Peek of My Presentation at Black Hat

by Patrick McGregor

Cold boot attacks aren’t theoretical academic exercises. Cold boot attacks are real. And they’re serious.

In the past few years, companies have poured hundreds of millions of dollars into full disk encryption technologies. Companies expect full disk encryption to reduce the risk of exposure of sensitive information such as intellectual property or customer data. Reality often deviates from what is expected, however. Researchers from Princeton shocked the industry earlier in 2008 when they released a research paper that showed that low-cost “Cold Boot” attacks could be used to defeat the security of most full disk encryption systems. They recently even published all the tools needed to do this at home!

Some have argued that Cold Boot attacks are not serious security threats. I disagree! First, an unskilled person can capitalize on the exploit using simple, automated steps and publicly available tools. In fact, Cold Boot attacks require nothing more than plugging a USB drive into a laptop. Second, the physical target of a Cold Boot attack, such as a laptop, is very easily obtainable (see the recent Ponemon report on laptops lost/stolen in airports – scary!). Third, although many laptops and desktops are stolen via random acts of theft, it is well known that some criminals profit from organized, calculated data theft. It is only a matter of time before we hear of a high-profile data breach that results from a simple Cold Boot attack.

I am excited to present at Black Hat several innovations for preventing Cold Boot attacks. In addition to summarizing how a Cold Boot attack works, I’ll describe four new software techniques for hardening full disk encryption against the attacks. The software technology was developed by myself, Tim Hollebeek, Alexander Volynkin, and Matt White. All of us work for BitArmor, an exciting security startup based in Pittsburgh. Here’s a sneak peek:

· Wash up: Wipe keys immediately before certain OS state transitions, such as before the computer shuts down or goes into hibernation mode – accessing the memory will yield nothing.

· Take advantage of BIOS memory smashing: By strategically placing keys in certain regions of memory, we can rely on the BIOS boot process to overwrite keys before any operating system can dump the contents of memory.

· Is it chilly in here?: Using built-in temperature sensors, we can lock down the system in reaction to temperature drops that may indicate a Cold Boot attack is in progress.

· Create a virtual enclave for keys: We can implement special cryptographic, OS and processor architecture techniques to provide robust protection for keys against the most aggressive cold boot attacks. By creating a “virtual secure enclave” for encryption keys in software, an attacker cannot extract critical keys from memory – even if the RAM is super-cooled.

Hope you can join us at Black Hat as we take an in-depth look at the future of full disk encryption technology.