Monday, April 26, 2010

The sweet spot in internet security.

New standards like HTML5 often try to address security problems by providing new security features. I think some of these are well-intentioned but are not moving us to a fundamentally more secure internet.

Let me commit blog suicide by starting with a chart that'll drive away most of my potential audience. (Bye :)
Introduces New ToolsImproves Security of Existing Tools
Large Audience
(Web Devs)
Limited. Slow to take hold. E.g., toStaticHtmlGood, but doesn't address zero-days. E.g. PHP magic quotes.
Small Audience
(Library Authors & Security folk)
Good, but won't help legacy apps. E.g. <iframe sandbox="...">The sweet spot. A (relatively) small group can address emerging threats quickly.
E.g., native JSON support

Small groups respond more quickly

The chart is broken down by the size of audience needed to work with the new feature. There are many more web programmers than library developers and web security professionals put together. Any tool that requires most web programmers to use it and use it consistently is limited in its effects. Conversely, if a small audience can change a system to be more secure, then it can have wide-reaching effects. For example, browser developers, a very small audience are now implementing native JSON support. This means that many of the websites out there that have old buggy versions of JSON.js for which there are known script injection exploits, will become more secure because those old libraries were written expecting JSON to become standard and so defer to the newer native implementation on browsers where it exists.

Fix existing code; don't only enable newer better code

The chart is also broken down by scope; will the changes only affect new code that uses new APIs, or does it fundamentally improve the security properties of existing code. If it requires developers to update code, then it can definitely help, but its effects will be very slow to be felt, since existing sites will have to be updated to use it. Website developers are notoriously conservative, and often rightly so ; you can go out of business by updating too soon and breaking your site for old browsers.

Not everything needs to be in the bottom-right box and not everything can be ; there are no silver bullets in security. It is good to have new tools, and to have tools targeted at the web development community at large, but we should always prefer the bottom-right.

Getting Ahead of the Game

New tools also have a problem. Many new security tools are reactions to emerging threats -- the threat model has changed so the HTML and Ecmascript committee respond with new tools that are suited to the new threat model.

But the threat model is only going to keep changing. To get to the sweet spot, we need meta-tools that help small groups of security professionals bolt new security policies onto existing code while maintaining backwards compatibility. And a way to get these changes onto the web at large by targeting a small group -- content aggregators and social hubs that use a plugin model are a good candidate. Ideally we'll get to the point where we have a patch-and-update cycle for the web. As the threat model changes, security specialists use the meta-tools to adapt existing systems to just keep working, but better.

I think the best candidate for meta-tools are software virtualization tools, like the membranes and proxies proposed for Ecmascript 5. And my project, Caja is aiming at providing that layer. We're not in the sweet-spot yet : we've virtualized the DOM and network so we're able to provide a huge array of security policies, but our questionable library support keeps us out of the sweet spot; we're working on that.

Friday, April 16, 2010

Talk on the semantic gap

Google's security team is expanding, so we're doing some recruiting. To help out, I gave a talk to Dawn Song's class at Berkeley.

In brief my argument was
  • Programming language design choices affect the kinds of vulnerabilities that programs written in those languages are susceptible to.
  • The source of these vulnerabilities is not just ignorance by programmers, but includes rational trade-offs between correctness/security and tersity, completeness, maintainability, efficiency, and other concerns.
  • A "semantic gap" exists where programmers (intentionally or unintentionally) use an abstraction that doesn't do quite what they want it to do.
  • Often this gap is innocuous (silent overflow in 64b increment) but sometimes it has catastrophic consequences (naive string interpolation → shell injection).
  • It is possible to close some of these gaps without unduly breaking existing programs by using static analysis, delayed binding, and opt-in defaults to infer intent.
Take a look at my slides.

"Security by Closing the Semantic Gap"

Security is about more than just cryptography; programming language design choices affect the way programmers design programs. We start with code samples in popular programming languages and show how it can be easy to write code that is almost correct, but that fails in ways that are catastrophic security-wise. We demonstrate how tweaking language definitions can close the "semantic gap," the difference between the intended effect of the code and its actual semantics which allows exploitable vulnerabilities to creep in.