lcamtuf's blog

p0f is back!

2012-01-10T09:34:00.001-08:00

I decided to spend some time rewriting and greatly improving my ancient but strangely popular passive fingerprinting tool:

http://lcamtuf.coredump.cx/p0f3/

Version 3 is a complete rewrite, bringing you much improved SYN and SYN+ACK fingerprinting capabilities, auto-calibrated uptime measurements, completely redone databases and signatures, new API design, IPv6 support (who knows, maybe it even works?), stateful traffic inspection with thorough cross-correlation of collected data, application-level fingerprinting modules (for HTTP now, more to come), and a lot more.

Notes about the post-XSS world

2011-12-19T23:56:00.000-08:00

Content Security Policy is gaining steam, and we've seen a flurry of other complementary approaches that share a common goal: to minimize the impact of markup injection vulnerabilities by preventing the attacker from executing unauthorized JavaScript. We are so accustomed to thinking about markup injection in terms of cross-site scripting that we don't question this approach - but perhaps we should?

This collection of notes is a very crude thought experiment in imagining the attack opportunities in a post-XSS world. The startling realization I had by the end of that half-baked effort is that the landscape would not change that much: The hypothetical universal deployment of CSP places some additional constraints on what you can do, but the differences are not as substantial as you may suspect. In that sense, the frameworks are conceptually similar to DEP, stack canaries, or ASLR: They make your life harder, but reliably prevent exploitation far less frequently than we would have thought.

Credit where credit is due: The idea for writing down some of the possible attack scenarios comes from Mario Heiderich and Elie Bursztein, who are aiming to write a more coherent and nuanced academic paper on this topic, complete with vectors of their design, and some very interesting 0-day bugs; I hope to be able to contribute to that work. In the meantime, though, it seems that everybody else is thinking out loud about the same problems - including Devdatta Akhawe and Collin Jackson - so I thought that sharing the current notes may be useful, even if the observations are not particularly groundbreaking.

X-Frame-Options, or solving the wrong problem

2011-12-10T14:44:00.001-08:00

On modern computers, JavaScript allows you to exploit the limits of human perception: you can open, reposition, and close browser windows, or load and navigate away from specific HTML documents, without giving the user any chance to register this event, let alone react consciously.

I have discussed some aspects of this problem in the past: my recent entry showcased an exploit that flips between two unrelated websites so quickly that you can't see it happening; and my earlier geolocation hack leveraged the delay between visual stimulus and premeditated response to attack browser security UIs.

A broader treatment of these problems - something that I consider to be one of the great unsolved problems in browser engineering - is given in "The Tangled Web". But today, I wanted to showcase another crude proof-of-concept illustrating why our response to clickjacking - and the treatment of it as a very narrow challenge specific to mouse clicks and <iframe> tags - is somewhat short-sighted. So, without further ado:

http://lcamtuf.coredump.cx/clickit/

There are more complicated but comprehensive approaches that may make it possible for web applications to ensure that they are given a certain amount of non-disrupted, meaningful screen time; but they are unpopular with browser vendors, and unlikely to fly any time soon.

The old switcharoo

2011-12-08T01:19:00.000-08:00

Another tiny proof-of-concept for the day:

http://lcamtuf.coredump.cx/switch/

While the idea is fairly trivial, it seems pretty frightening to me - and neatly illustrates one of the points I'm making in The Tangled Web. I highly doubt that even the most proficient and attentive users would be able to spot this happening in the wild.

(If you don't get it, try again, and follow instructions on the screen.)

Interesting results can be also achieved in some browsers with history.back(), but I'll leave this as an exercise for readers. The same goes for the implications it has for clickjacking, drag-and-drop, and other attacks normally associated with frames.

PS. Another silly proof-of-concept as a bonus: click here.

CSS :visited may be a bit overrated

2011-12-02T16:04:00.000-08:00

OK, second time is a charm. This script is probably of some peripheral interest:

http://lcamtuf.coredump.cx/cachetime/

In the past two years or so, a majority of browser vendors decided to take a drastic step of severely crippling CSS :visited selectors in order to prevent websites from stealing your browsing history.

It is widely believed that techniques such as cache timing may theoretically offer comparable insights, but the attacks demonstrated so far seemed unconvincing. Among other faults, they relied on destructive, one-shot testing that altered the state of the examined cache; produced only probabilistic results; and were far too slow and noisy to be practically useful. Consequently, no serious attempts to address the underlying weakness have been made.

My proof of concept is fairly crude, and will fail for a minority of readers; but in my testing, it offers reliable, high-performance, non-destructive cache inspection that blurs the boundary between :visited and all the "less interesting" techniques.

"The Tangled Web" is out

2011-11-15T09:00:00.000-08:00

Okay, okay, it's official. You can now buy The Tangled Web from Amazon, Barnes & Noble, and all the other usual retailers for around $30. You can also order directly from the publisher, in which case, discount code 939758568 gets you 30% off.

No Starch provides a complimentary, DRM-free PDF, Mobi, and ePub bundle with every paper copy; you can also buy e-book edition separately. Kindle and other third-party formats should be available very soon.

More info about the book itself, including a sample chapter, can be found on this page.

In praise of anarchy: metrics are holding you back

2011-11-04T21:19:00.000-07:00

It is a comforting to think about information security as a form of computer science - but the reality of securing complex enterprises is as unscientific as it gets. We can theoretize how to write perfectly secure software, but no large organization will ever be in a meaningful vicinity of that goal. We can also try to objectively measure our performance, and the resilience of our defenses - but by doing so, we casually stroll into a trap.

Why? I think there are two qualities that make all the difference in our line of work. One of them is adaptability - the capacity to identify and respond to new business circumstances and incremental risks that appear every day. The other is agility - the ability to make changes really fast. Despite its hypnotic allure, perfection is not a practical trait; in fact, I'm tempted to say that it is not that desirable to begin with.

Almost every framework for constructing security metrics is centered around that last pursuit - perfection. It may not seem that way, but it's usually the bottom line: the whole idea is to entice security teams to define more or less static benchmarks of their performance. From that follows the focus on continually improving the readings in order to demonstrate progress.

Many frameworks also promise to advance one's adaptability and agility, but that outcome is very seldom true. These two attributes depend entirely on having bright, inquisitive security engineers thriving in a healthy corporate culture. A dysfunctional organization, or a security team with no technical insight, will find false comfort in a checklist and a set of indicators - but will not be able to competently respond to the threats they need to worry about the most.

A healthy team is no better off: they risk being lulled into complacency by linking their apparent performance to the result of a recurring numerical measurement. It's not that taking measurements is a bad idea; in fact it's an indispensable tool of our trade. But using metrics as long-term performance indicators is a very dangerous path: they do not really tell you how secure you are, because we have absolutely no clue how to compute that. Instead, by focusing on hundreds of trivial and often irrelevant data points, they take your eyes off the new and the unknown.

And this brings me to the other concern: the existence of predefined benchmarks impairs flexibility. Quite simply, yesterday's approach, enshrined in quarterly statistics and hundreds of pages of policy docs, will always overstay it welcome. It's not that the security landscape is constantly undergoing dramatic shifts; but if you don't observe the environment and adjust your course and goals daily, the errors do accumulate... until there is no going back.

Good news, everyone!

2011-10-28T17:56:00.000-07:00

No Starch Press just posted a sample chapter for The Tangled Web. You can grab the PDF here and see what it's all about. The book itself should be available by November 15; you can also preorder on Amazon.

If you don't know what this is all about, you can also head over to the home page of the book; but the bottom line is that I think it's the first-ever reasonably detailed examination of the browser security model and its evolution through the years - and really, that's something you just need to know to develop modern web apps.

PS. It's apparently always April Fools' at Microsoft!

An origin is forever

2011-10-02T14:05:00.001-07:00

This post is inspired chiefly by the work of Artur Janc.

The Internet is a pretty seedy place, yet we are quite willing to hand over our secrets to a small group or trusted web apps. Heck, in recent years, we also started giving them capabilities: social networking sites often get to see your geolocation, and your instant messenger may be able to access your microphone or webcam feeds. Some of this does not even require your initial consent: certain browsers and plugins come with hardcoded domains that are permitted to install software updates, or change system settings at a whim.

The push toward web application capabilities is somewhat frightening once you realize that the boundaries between web applications are very poorly defined, and that nobody is trying to solve that uncomfortable problem first. Look at the scoping rules for JavaScript DOM access, for HTTP cookies, and for auxiliary mechanisms such as password managers: they not only differ substantially, but routinely interfere with each other in destructive ways. Compartmentalizing complex web applications should be a breeze, but instead, it's an impenetrable form of art.

Worse, content isolation on the web is very superficial - so even if the boundaries can be drawn, most types of privileged contexts can't distance themselves from the rest of the world, and expose just a handful of well-defined APIs. Instead, every non-trivial web application needs to heavily compensate for the risk of clickjacking, cross-request forgery, reflected cross-site scripting, and dozens of other attacks of that sort. All the developers eventually fail, by the way: show me a domain with no history of XSS, and I will show you a web application nobody cares about.

Unlike some other tough challenges in browser engineering, the risks of living with privileged applications could mitigated fairly nicely simply by requiring some effort up front: even without inventing any new security mechanisms, you could require applications to use origin cookies, have a sensible CSP policy, and use HSTS, before being allowed to prompt for extra privileges. It's not impossible to do something meaningful - it's just unpopular with the creators of privileged APIs.

But the problems with the clarity of robustness of application boundaries aside, there is also a third, perhaps more fascinating issue: what do you do if your web application execution context becomes corrupted in some way? As it turns out, there is no mechanism for the server to say that from now on, it wants to have a clean slate, and that the browser should drop or at least isolate any already running code, or previously stored data.

This seemingly odd wish is actually critical to web application security. For example, let's assume there is an XSS vulnerability in a web mail system or a social networking application. Because of the convenient but unfortunate design of HTML, such vulnerabilities are unavoidable, but we seldom wonder if it's possible to cleanly and predictably recover from them. Intuitively, patching the underlying bug, invalidating session cookies, and perhaps forcing password change, is all it should take; in fact, applications using httponly cookies can often skip the last two steps.

Alas, an once-compromised web origin can stay tainted indefinitely. At the very minimum, the attacker is in full control for as long as the user keeps the once-affected website open in any browser window; with the advent of portable computers, it is not uncommon for users to keep a single commonly used website open for weeks. During that period, there is nothing the legitimate owner of the site can do - and in fact, there is no robust way to gauge if the infection is still going on. And hey, it gets better: if content from the compromised origin is commonly embedded on third-party pages (think syndicated "like" buttons or advertisements), with some luck, attacker's JavaScript may become practically invincible, surviving closing the original application and the deletion of browser cache. If that doesn't give you a pause, it should.

And let's not forget open wireless networks: the problem there is about as bad. It does not matter that you are not logged into anything sensitive while visiting Starbucks. An invisible frame, a strategic write to localStorage, or a bit of DNS or cache poisoning, is all it takes for the attacker to automatically elevate his privileges the moment you return to a safe environment and log back in.

With all that, and with the proliferation of mechanisms such as web workers and offline apps, we are rapidly approaching a point where recovering from a trivial XSS bug and other common web security lapses is getting almost as punishing as recovering from RCE - and for no good reason, too. Sure: today, it's so easy to phish users or exploit real RCE bugs, that backdooring web origins is not worth the effort. But in a not-too-distant future, that balance may shift.

Critical (of) severity

2011-09-09T21:33:00.000-07:00

You can tell when a person is desperate to appear authoritative: they often litter their speech with unnecessary, roundabout verbiage. To some listeners, this sounds smart. To many others, it's obtuse and pompous.

I think that one of the cornerstones of vulnerability management is just an example of that. I am talking about the concept of vulnerability severities: I believe that they serve no real purpose, other than obfuscating the true intent of speech.

It's not that we don't need a codified taxonomy; but the term "severity" and the abstract levels attached to it ("critical", "high", "medium", "low") are a remarkably poor proxy for what we actually want to say.

The notion of severity is used in two distinct settings:

In a position of authority: For example, when an internal security team is communicating with developers. In this case, the intent of assigning severity is to instruct the developer to do one of the following:
- Drop all other work and fix the bug now.
- Fix the issue in a couple of days.
- Fix at own leisure, or not at all.
In an advisory position: Say, when a vendor is notifying end users about the availability of a fix. In this case, the actual message usually is any of the following:
- You are in imminent danger. Patch now.
- You are at a limited risk, but prompt action is advisable.
- We don't think there is a substantial risk.

Every time, the messages are very simple. Yet, instead of just saying it out loud, we create one set of guidelines for the security team to map their assessment to an ambiguous codeword; and then furnish a second lengthy phrasebook for the final recipient of a message, to map the codeword to something they can act on.

Only we're not running a numbers station: we're trying to tell people something very important, and we need them to understand us right away. There is no way around the fact that terms such as "critical" or "high" intuitively mean different things to different people, and almost certainly not just the thing you actually wanted to say. If the severity needs to be accompanied with several pages of organization-specific explanatory text, something is horribly wrong.

Instead of "highly critical", just start telling your users "patch right away".

So you want to write a security book?

2011-08-29T12:15:00.000-07:00

Now that I am done with my side project, I wanted to post a note about something that my colleagues frequently ask about: the reality of publishing a security-themed book.

The most important advice I can give is to start with a reality check: writing for technical audiences will probably not make you rich. You will invest somewhere between 200 and 1,000 hours of work over the course of several months. In the next two years, you will likely sell from 1,000 to 50,000 copies (10,000 is pretty good already). Your cut is between $2 and $5 per copy (that's 10-20% of the actual sale price, which in turn is usually around 50% of the cover price); proportionally less if there are multiple authors involved.

The bottom line is that your motivation needs to be something other than money. If there are no quality, up-to-date reference materials in your field of expertise, or if you just have something interesting to share, go for it. If you just want to earn some cash, random consulting gigs would net you more.

If you are still serious about the plan, the next step is choosing between a traditional publisher, and doing all the work yourself. I recommend the former. There are some reputable self-published security books (say, Fyodor's), and if you pursue this route, you will be able to get a slightly larger slice of the revenue pie. That said, you lose some important benefits:

You will not get professional editorial feedback. Having an independent sanity check from a person who publishes books for a living helps you set the style and flow of the chapters, and arrange them reasonably. This is harder than it seems. Even the best ideas look bad when presented poorly.
You will have to take care of technical illustrations, page layout, indexes, and so on - requiring some talent, and easily adding 50-100 hours of work into the mix.
You will have to pay for technical editing and proofreading - or ship the book with typos and grammar errors, which never helps.
You will have to invest some effort into marketing, accounting, etc.

If you have a decent proposal, you can approach publishers out of the blue, and pick the one you want to work with; for time being, the demand for infosec authors seems to be higher than the supply. All the publishers will all offer you roughly the same financial terms, but there are some interesting differences in what you will get in return. I know quite a few authors signed up with one of the major publishing houses, and very unhappy about not receiving any editorial attention past the first chapter or two; or not being able to get an illustrator assigned to the project, and having to do the work themselves. In these cases, one has to wonder what the publisher is doing to earn its fees.

So, ask around. For example, in comparison to said publisher, my experiences with No Starch Press have been very good.

The subtle / deadly problem with CSP

2011-08-26T21:34:00.000-07:00

Content Security Policy is a promising new security mechanism deployed in Firefox, and on its way to WebKit. It aims to be many things - but its most important aspect is the ability to restrict the permissible sources of JavaScript code in the policed HTML document. In this capacity, CSP is hoped to greatly mitigate the impact of cross-site scripting flaws: the attacker will need to find not only a markup injection vulnerability, but also gain the ability to host a snippet of malicious JavaScript in one of of the whitelisted locations. Intuitively, that second part is a much more difficult task.

Content Security Policy is sometimes criticized on the grounds of its complexity, potential performance impact, or its somewhat ill-specified scope - but I suspect that its most significant weakness lies elsewhere. The key issue is that the granularity of CSP is limited to SOP origins: that is, you can permit scripts from http://www1.mysite.com:1234/, or perhaps from a wildcard such as *.mysite.com - but you can't be any more precise. I am fairly certain that in a majority of real-world cases, this will undo many of the apparent benefits of the scheme.

To understand the problem, it is important to note that in modern times, almost every single domain (be it mozilla.org or microsoft.com) hosts dozens of largely separate web applications consisting of hundreds of unrelated scripts - quite often including normally inactive components used for testing and debugging needs. In this setting, CSP will prevent the attacker from directly injecting his own code on the vulnerable page - but will still allow him to put the targeted web application in a dangerously inconsistent state, simply by loading select existing scripts in the incorrect context or in an unusual sequence. The history of vulnerabilities in non-web software strongly implies that program state corruption flaws will be exploitable more often than we may be inclined to suspect.

If that possibility is unconvincing, consider another risk: the attacker loading a subresource that is not a genuine script, but could be plausibly mistaken for one. Examples of this include an user-supplied text file, an image with a particular plain-text string inside, or even a seemingly benign XHTML document (thanks to E4X). The authors of CSP eventually noticed this unexpected weakness, and decided to plug the hole by requiring a whitelisted Content-Type for any CSP-controlled scripts - but even this approach may be insufficient. That's because of the exceedingly common practice of offering publicly-reachable JSONP interfaces for which the caller has the ability to specify the name of the callback function, e.g.:

GET /store_locator_api.cgi?zip=90210&callback=myResultParser HTTP/1.0
...

HTTP/1.0 200 OK
Content-Type: application/x-javascript
...
myResultParser({ "store_name": "Spacely Space Sprockets",
                 "street": ... });

Having such an API anywhere within a CSP-permitted origin is a sudden risk, and may be trivially leveraged by the attacker to call arbitrary functions in the code (perhaps with attacker-dependent parameters, too). Worse yet, if the callback string is not constrained to alphanumerics – after all, until now, there was no compelling reason to do so – specifying callback=alert(1);// will simply bypass CSP right away.

The bottom line is that CSP will require web masters not only to create a sensible policy, but also thoroughly comb every inch of the whitelisted domains for a number of highly counterintuitive but potentially deadly irregularities like this. And that's the tragedy of origin scoping: if people were good at reviewing their sites for subtle issues, we would not be needing XSS defenses to begin with.

Using View > Encoding can kill you (in a manner of speaking)

2011-04-09T21:01:00.001-07:00

Here's an interesting tidbit: you should never use the View > Encoding menu in any browser unless you fully trust the visited website.

Picking an alternative encoding through that menu overrides the character set not only for the top-level document, but also for all the nested frames - even if they happen to be cross-domain or hidden from view. And that may very well enable the owner of the visited page to carry out an XSS attack against a random third-party application without your knowledge.

Most security researchers associate encoding-related XSS problems with UTF-7, a somewhat preposterous and unnecessary encoding scheme that, by design, allows overlong encoding of 7-bit ASCII values (with disastrous consequences for HTML parsing). Not all browsers support UTF-7, and users are not likely to make that choice in the aforementioned menu. So, we're fine, right?

Well, not exactly. Many other, still popular multi-byte encodings, including Shift JIS or EUC-*, are also fairly problematic: their parsers often suffer from character consumption bugs, and in contrast to UTF-8, relatively little attention has been given to cleaning this up.

For example, with forced Shift JIS, this input is likely to be exploitable:

<img src="http://fuzzybunnies.com/[0xE0]">
  ...this is still a part of the markup...
  " onerror="alert('Hi mom!')" x="
  ...

Simple demo here.

Pwn2own considered (somewhat) harmful

2011-03-12T13:54:00.001-08:00

I think that hacking challenges and bug bounty programs can be extremely valuable. This is true when they involve transparent, sustained efforts to evaluate the security of a particular platform. For example, I believe that there is a substantial value in Mozilla bug bounties, or in the Chrome reward program. These programs greatly improve the security of the browsers in question, occasionally advance our understanding of web security, and provide tons of statistical data about vendor response processes and attitudes toward security flaws. That last part is arguably the most important metric when dealing with code so complex that for better or worse, it is unlikely to ever be perfectly safe.

I also think that Pwn2own, an annual browser hacking contest run by TippingPoint, does not deliver the same value. The formula of the contest boils down to this: once a year, a single, secretly developed exploit is exchanged for a substantial amount of money. No information about the flaw or its back story is revealed in the process, and given that this trade is negligible in comparison to the annual volume of browser vulnerabilities, there is absolutely no intrinsic value in observing it.

That, alone, is not a compelling criticism; at best, it's a reason not to watch. But then, there are some negative consequences, too: it is in the interest of the conference and contest organizers, and the participating researchers, to get publicity for their findings - and journalists, who do not necessarily have a holistic view of the day-to-day browser security research, embrace such high-profile developments with disproportionate enthusiasm. The resulting ecstatic press coverage ultimately undermines any attempt to have a meaningful and reasonable discussion about the state of browser security.

Take this quote, which likely will be repeated in every Safari-related story for the next twelve months:

"A team was able to exploit Safari to exploit a MacBook Air in five seconds. Yes, five seconds - less time than it takes most people just to type 'Safari got hacked in less than five seconds'."

That's remarkable, but also completely wrong. It takes days or weeks to find and exploit a vulnerability, and Pwn2own is no exception: the actual exploits are prepared months or weeks in advance, and simply executed on the day the contest takes place. I do not think there is a single person in the information security industry who would say that the discovery of a normal browser vulnerability is a notable event: several hundred such flaws are discovered and resolved every year in every browser, as evidenced by release notes maintained by the vendors with varying degrees of accuracy. Neither the fact that somebody discovered a vulnerability before Pwn2own, nor that this person needed needed five seconds to execute that pre-made code, is a useful measure of anything.

Similarly, the survival of Firefox and Chrome intuitively makes me happy, because I know that these browsers give a lot of thought to security - but I do not think that Pwn2own is a meaningful testament to this. Perhaps these two vendors merely patched up the vulnerability somebody wanted to use, and there was not enough time to find a new one. Or perhaps nobody attending the event (which brings together only a tiny fraction of the infosec community) had the expertise and the inclination to target this particular browser.

Yes, there are vendors who lag behind the rest when it comes to vulnerability response and proactive security work; and there are some hard problems we still have to solve to make the web a safer environment. But the headlines inspired by Pwn2own (and probably encouraged by the organizers) are very unfair, and unnecessarily alienate the parties who should be paying attention to their security posture. Investigating real data, and asking some hard-hitting questions, can make more of a difference... and if done right, it can be more fun.

A note on an MHTML vulnerability

2011-03-11T13:04:00.000-08:00

There is an ongoing discussion about a recently disclosed, public vulnerability in Microsoft Internet Explorer, and its significance to web application developers. Several of my colleagues investigated this problem in the past few weeks, and so, I wanted to share our findings.

As some of you may be aware, Microsoft Internet Explorer supports MHTML, a simple container format that uses MIME encapsulation (nominally multipart/related) to combine several documents into a single file. Each container may consist of a number of possibly base64-encoded documents, with their content type determined solely by the inline MIME data.

Perhaps by the virtue of not having cross-browser support, the MHTML format is not commonly used on the web - but it is employed by Internet Explorer itself to save downloaded pages to disk; and embraced by some third-party applications to deliver HTML-based documentation and help files.

To facilitate access to MHTML containers, the browser also supports a special mhtml: URL scheme, followed by a fully-qualified URL from which the document is to be retrieved; a "!" delimiter; and the name of the target resource inside the container. Unfortunately, when MHTML containers are accessed over protocols that provide other, normally authoritative means for specifying document type (e.g. Content-Type in HTTP traffic), this protocol-level information is ignored, and a very lax MIME envelope parser is invoked on the retrieved document, instead. The behavior of this parser is not documented, but it appears that in many cases, adequately sanitized user input appearing on HTML pages, in JSON responses, CSV exports, image metadata, and so forth, is sufficient to trick it into treating the underlying document as valid MHTML. All that is needed to keep this parser happy is the ability to place several alphanumeric and punctuation characters on the target page, in several separate lines.

The payload inside such an unintentionally served "MHTML container" is able to execute JavaScript, and has same-origin DOM access to the originating domain; with some minimal effort, it is also able to access to domain-specific cookies. Therefore, this behavior essentially represents a universal cross-site scripting flaw that affects a significant proportion of all sensitive web applications on the Internet.

Based on this 2007 advisory, it appears that a variant of this issue first appeared in 2004, and has been independently re-discovered several times in that timeframe. In 2006, the vendor reportedly acknowledged the behavior as "by design"; but in 2007, partial mitigations against the attack were rolled out as a part of MS07-034 (CVE-2007-2225). Unfortunately, these mitigations did not extend to a slightly modified attack published in the January 2011 post to the full-disclosure@ mailing list.

It appears that the affected sites generally have very little recourse to stop the attack: it is very difficult to block the offending input patterns perfectly, and there may be no reliable way to distinguish between MHTML-related requests and certain other types of navigation (e.g., <embed> loads). A highly experimental server-side workaround devised by Robert Swiecki may involve returning HTTP code 201 Created rather than 200 OK when encountering vulnerable User-Agent strings - as these codes are recognized by most browsers, but seem to confuse the MHTML fetcher itself.

Until the problem is addressed by the vendor through Windows Update, I would urge users to consider installing a FixIt tool released by Microsoft as an interim workaround.

Update: see this announcement for more.

The other reason to beware ExternalInterface.call()

2011-03-06T20:40:00.000-08:00

Adobe Flash has a function called ExternalInterface.call(...), which implements a JavaScript bridge to the hosting page. It takes two parameters: the first one is the name of the JavaScript function to call. The second one is a string to pass to this function.

It is understood that the first parameter should not be attacker-controlled (of course, mistakes happen :-). It is also understood that there is no inherent harm in putting user input in the second parameter, if the callback function itself is not behaving stupidly; in fact, Adobe documentation gives an example that follows this very pattern:

... ExternalInterface.call("sendToJavaScript", input.text); ...

Such a call would be translated to an eval(...) statement injected on the embedding page. This statement looks roughly the following way:

try { __flash__toXML(sendToJavaScript, "value of input.text")); } catch (e) { "<undefined/>"; }

When writing the supporting code behind this call, the authors remembered to use backslash escaping when outputting the second parameter: hello"world becomes hello\"world. Unfortunately, they overlooked the need to escape any stray backslash characters, too.

So, try to figure out what happens if the value of input.text is set to the following string:

Hello world!\"+alert(1)); } catch(e) {} //

I reported this problem to Adobe in March 2010. In March 2011, after following up, I received the following response:

"We have not made any change to this behavior for backwards compatibility reasons."

Caveat emptor :-)

Warning: OBJECT and EMBED are inherently unsafe

2011-03-06T11:58:00.000-08:00

Let's say that you maintain an online discussion forum. Assuming that you explicitly specify the type= parameter in your <object> or <embed> markup, what are the security consequences of allowing users to embed third-party Flash movies in their posts when you enforce the appropriate security restrictions on your end (allowScriptAccess, allowNetworking, allowFullScreen all set to none)? Or, to make things simpler, how about permitting a straightforward video file, with type=video/x-ms-wmv?

If you think this is safe, you may want to know that the HTML5 spec has a different view. The specification effectively takes away the ability for any single party to decide how a particular plugin document should be handled by the browser. Under the new algorithm, instead of your funny cat video, you may accidentally end up embedding Java, which has unconditional access to the DOM of the embedding page through DOMService. Whoops, looks like you are owned now.

According to the spec, if your visitor's browser has, say, a Windows Media Player plugin that recognizes the type=video/x-ms-wmv value on your webpage, that plugin will be used regardless of Content-Type. This part is intuitive. Alas, if the plugin is not found, the specification compels the software to look at Content-Type next, giving the hosting party an opportunity to override the intent specified on your end.

To further complicate the picture, in some circumstances, browsers may also ignore both type= and Content-Type values: for example, Internet Explorer and WebKit browsers will play Flash videos served with Content-Type: pants/whatever and loaded with type=certainly/not-flash just because a stray .swf file extension is spotted somewhere in the URL. The file name signal is problematic, as it can usually be tampered with by whoever provides the URL. This strategy brings a yet another player into the picture, and each party can sabotage the security assurances sought by the rest.

It would be more reasonable to keep the behavior of <object> and <embed> consistent with that of other type-specific subresource tags (e.g., <applet>, <img>, or <script>), and give control over how the document is rendered to whoever authored the markup. This approach is still not without peril, because it makes it impossible for some sites to indicate that a particular text/plain or image/jpeg response is not meant to be interpreted as a malicious applet. But that last problem can be fixed by requiring Content-Type and type= to match, perhaps through an opt-in mechanism controlled with a new HTTP header. And in any case, the proposed logic does not help.

In the end, the currently specified behavior seems highly counterintuitive, and undoes all the work plugin that vendors such as Adobe or Microsoft put into adding security controls to ensure that their plugin content is reasonably safe to embed across domains that do not fully trust each other.

Test cases here. Joshua Stein also reports that they confuse Flash-blocking tools.

Give me A, give me P, give me T

2011-02-21T20:31:00.001-08:00

Following my earlier entry about HBGary, several people asked if I did not believe in the fashionable concept of Advanced Persistent Threats.

My view is a bit different. Any organization that focuses solely on prevention of non-targeted attacks is making a grave mistake. This hasn't changed at all in the past two decades: attackers interested in a particular target, and willing to spend several weeks on such a pursuit, were always a huge problem. In a vast majority of documented cases, they did not need to be unusually sophisticated to succeed, too - and in proportion to the size of the online economy, I don't think they are more numerous than, say, ten years ago.

Fending off these attackers in large and complex environments is very difficult, and requires in-depth in-house expertise, lots of ingenuity - and even then, it may occasionally fail. Alas, at the behest of vendors and infosec pundits, many organizations made exactly the wrong choice, and spent the bulk of their efforts on ISO 27002, PCI, SOX, and off-the-shelf AV and IDS tools - building a more measurable and familiar, but ultimately vulnerable, world.

It is increasingly evident that the value of these solutions in containing determined attackers is fairly small. The parties involved would prefer to say that they had done the right thing, and the threat landscape has changed in the meantime, instead. But the claim that they are facing a brand new, incredibly sophisticated adversary is a very self-serving one.

So, I am simply saddened by the emphasis on the "advanced" part of the term, and the Cold War rhetoric employed to push even more expensive and ultimately meaningless products and approaches. Whether you are a government agency or a Fortune 500 corporation, chances are, buying services such as 0-day vulnerability notifications or botnet monitoring is not an efficient use of your money.

Possibly the most fascinating HTML parser behavior ever

2011-02-18T10:02:00.000-08:00

I learned about this tidbit from sirdarckcat. It is in no way new, but the trick is so cute that I just could not resist sharing.

When parsing HTML documents, browsers recognize two methods of specifying tag parameter values: a "bare" form (such as <img src=image.jpg>), which is terminated by angle brackets, whitespaces, and so on; and a quoted form (<img src="image.jpg">) which is terminated only by a matching quote.

Every browser makes the decision by looking at the first non-whitespace character after the name=value separator. If this happens to be a single or a double quotation mark, the second parsing strategy is used; otherwise, the first method is a go. Internet Explorer also recognizes backticks (`) as a faux quote, leading to security flaws in a fair number of HTML filters - but even with this quirk, the behavior is still pretty straightforward. In particular, in the following example, stray quotes will not have any effect on how the tag is interpreted:

<a href=http://www.example.com/?">This text is not a tag parameter anymore.">Click me</a>

But here's the thing: Internet Explorer seems to be doing a substring search for an equals sign followed by a quote anywhere in the parameter name=value pair. Therefore, the following syntax will be parsed in a very different way:

<a href=http://www.example.com/?=">This is still a part of markup indeed!">Click me</a>

It's one of the most unique and surreal HTML parser quirks I am aware of (and it survives to this day in Internet Explorer 9). In principle, it allows any server-side HTML filter to get out of sync with the browser, leading to parameter splitting and tag consumption. In reality, it has a limited practical significance: if your HTML filter is relaxed enough to allow this syntax to go through, it is probably already vulnerable to the abuse of other syntax tricks.

The world of HBGary

2011-02-16T00:29:00.001-08:00

I am truly frightened by the emerging picture of a compromise of HBGary Federal. And it is not because the allegation of a disturbing business proposal to, among other things, intimidate a well-known journalist and indiscriminately distribute malware.

It is also not because of the likelihood that a similarly opportunistic and amoral corporate culture is endemic to the entire sector - a suspicion made more credible after noticing that the leaked proposal uses the letterhead of another government-friendly company, Palantir, and generously credits a third one: Berico.

No, that's not it. The reason why I am frightened is the emergence of a new class of government contractors - a class that depends on the perpetration of an alluring, yet completely irrelevant belief: that an incredibly sophisticated and determined adversary is constantly scheming to wage a devastating cyber-war against everything we hold dear.

It is an ugly truth: for the past 10 or 15 years, the security industry has made virtually no progress in helping large organizations deal not with Bond-esque villains, but with the simple threat of bored kids and geeks with an agenda - their most significant, and most unpredictable foe. It is tempting to frame the constant stream of high-profile failures as a proof for the evolution of your adversary. But when you realize that almost every single large institution can probably be compromised by a moderately skilled attacker, this explanation just does not ring true.

The inability to solve this increasingly pressing problem is no reason to celebrate - and even less of a reason to push for preposterous, unnecessary spending on silly intelligence services, or to promote overreaching and ill-defined regulation. If anything, it is a reason to reflect on our mistakes and perhaps go back to the drawing board. But between all the talk of cyber-jihad and APT, this unpleasant message is easy to overlook.

...

On the flip side, the difficulty of securing a complex enterprise hardly applies to specialized, well-funded security outlets: that one problem is easy to fix. These companies should have an abundance of expertise and resources to tightly manage and monitor their relatively small and self-contained networks. Similarly, their employees can be reasonably expected to exercise above-average restraint and a good dose of common sense. It is an uncomplicated matter of living up to your own bold claims.

From this perspective, the purported details of the attack on HBGary - a horribly vulnerable, obscure CMS; unpatched internal systems; careless password reuse across corporate systems and Twitter or LinkedIn; and trivial susceptibility to e-mail phishing - are a truly fascinating detail. These tidbits seem to imply either extreme cynicism of their staff... or an ubelievable level of cluelessness. And from a broader perspective, both of these options are pretty scary.

Oh, the ironic part? Despite all the lofty rhetoric, looks like in the end, they have been undone by just a bunch of bored kids.

So you think your capability model is bad?

2011-02-04T12:37:00.000-08:00

In his recent post, Brad Spengler mocked the Linux capability system - a somewhat ill-conceived effort to add modern access controls on top of the traditional Unix permission model. Brad noted that most of the CAP_* boundaries are not particularly well aligned with the underlying OS, and not internally consistent - and therefore, much of the resulting granularity is almost completely meaningless: for example, there is no substantial benefit of giving an application just CAP_SYS_MODULE, CAP_MKNOD, CAP_SYS_PTRACE, or CAP_SYS_TTY_CONFIG privileges, as all of these are essentially equivalent to giving root access to the ACLed program.

I thought it would be interesting to engage in a similar thought experiment for the browser environment - after all, it is quickly becoming the equivalent of a complex and powerful operating system for modern web applications.

As far as normal web applications are considered, there is no concept of a globally privileged access level; permissions to access content on client and server side are controlled by four separate, implicit authentication schemes, instead:

HTTP cookies (reference):
- Visibility: explicitly visible to client and server code.
- Scoping: scoped to the originating functional domain (or subdomain thereof). Can be additionally scoped to a specific document path; this meaningless as a security boundary.
- Notes: a kludge to allow scoping to HTTPS only is present - the secure flag; this mechanism offers far less benefit than it could, because HTTP and HTTPS cookie jars are not isolated otherwise.
Legacy HTTP authentication (reference):
- Visibility: explicitly visible to server code; sometimes exposed to client code.
- Scoping: scoped to a protocol-host name-port tuple. In some but not all browsers, additionally scoped to a specific request path; or to a server-declared "realm" string.
Client SSL certificates:
- Visbility: visible to server code only.
- Scoping: scoped globally in the browser.
- Notes: in most but not all browsers, user must confirm sending a certificate to a particular destination host name once within a browsing session.
Script origin:
- Visibility: principally visible to client code only; unreliably disclosed to server on some requests.
- Scoping: origin is defined by a protocol-host tuple; port number is also included in most, but not all, browsers.
Notably absent: network context. The information about the circumstances in which a particular credential is established is not analyzed or preserved. Because of the persistence of web content, this poses a significant problem with public wireless networks.

The above set of overlapping credential schemes is then used to build a number of client-side mechanisms with a range of conflicting security boundaries:

Subresource loads (reference):
- Relevant to: the ability to load images, scripts, plugins, frames, and other types of embedded content; and to navigate the top-level window.
- Security boundaries: this capability is not generally restricted in modern browsers. Certain response types can be read directly across websites; others can be requested, and then examined only indirectly.
- Interactions: server response can and often will be tied to server-recognized credentials, including cookies, SSL certificates, or client-supplied origin (non-universal Origin or unsafe Referer header).
DOM access (reference):
- Relevant to: the ability to directly access loaded documents through the JavaScript Document Object Model - a method considerably more versatile than the previous scenario.
- Security boundaries: privilege scoped to origin; when origin is not fully qualified, behavior is undefined. Scope can be expanded to functional domain via document.domain; this has unintended consequences and is usually unsafe.
- Interactions: access is not tied to any other credentials; for example, replacing or removing cookies does not revoke access from old documents to the new ones, and vice versa.
Most types of browser API access:
- Relevant to: access to browser-managed interfaces such as postMessage(), localStorage, geolocation information, pop-up privileges, and so forth.
- Security boundaries: permissions theoretically scoped to origin, but Firefox and MSIE currently violate this rule for localStorage and sessionStorage, and scope to host; when origin is not fully qualified, behavior is undefined. Additional top-level window scoping is introduced for sessionStorage. Unlike with DOM access, these permissions are not affected by document.domain.
- Interactions: access is not tied to any other credentials.
XMLHttpRequest API reference):
- Relevant to: the ability to make almost arbitrary, credential-bearing HTTP requests, and read back raw responses, from within JavaScript code.
- Security boundaries: permission scoped to origin; when origin is not fully qualified, behavior is undefined. Port number is always compared, even in browsers that do not include it in other origin checks. Scope not affected by document.domain.
- Notes: access to another origin is possible after a simple HTTP handshake in modern browsers.
- Interactions: server response can and often will be tied to server-recognized credentials.
Web sockets API (reference):
- Relevant to: a new HTML5 feature in WebKit browsers, allowing scripts to establish long-lived stream connections to arbitrary servers.
- Security boundaries: scripts can access any server and port after a successful completion of a challenge-response handshake.
- Interactions: server is provided with requestor's origin information and cookies to authenticate the request.
Cookie access (reference):
- Relevant to: the ability to read or write the document.cookie property.
- Security boundary: content is scoped to a particular domain, path, and secure flag level, as governed by cookie scoping rules. Cookies may also be tagged as httponly, preventing reads (but not writes) from within JavaScript.
- Notes: document.cookie has highly asymmetrical write and read behavior; it is possible to overwrite cookies for subdomains, paths, or secure / httponly settings well outside setter's nominal visibility.
- Interactions: not tied to any other credentials or network context. Substantially incompatible with DOM access boundaries, affecting both schemes: DOM rules make cookie path scoping useless, while lax cookie scoping often undermines DOM origin-based isolation in cookie-authenticated web applications.
Password managers:
- Relevant to: password auto-completion capabilities integrated with most browsers.
- Security boundaries: stored credentials are scoped to origin, path, and form layout; only the first part constitutes a meaningful security boundary.
- Notes: in some but not all browsers, an explicit user action needed to expose credentials to the origin.
- Interactions: incompatibility with DOM access rules makes path and form scoping useless from security perspective. Existing credentials are not taken into account when completing form data. Saved passwords are generally converted to cookie-based credentials by the server using an application-specific mapping.
Cache control:
- Relevant to: implicit and explicit retrieval of previously cached documents when requested by the client-side code.
- Security boundaries: cached content is scoped to original request URL and POST payload; once retrieved from the cache, it follows the same rules as any fresh response would.
- Interactions: caches may be shared by multiple users. Cached content is not explicitly tied to any credentials - logging out does not invalidate cached documents, and does not prevent same-origin access later on. If shared proxies are accidentally permitted to cache the response, it may be returned to other users, even though their requests do not bear relevant cookies.
Internet Explorer zone model:
- Relevant to: a proprietary mechanism that allows elevated privileges to be granted to certain content; and to prevent navigation between certain groups of websites.
- Security boundaries: a mix of origin scoping for explicitly defined URLs; protocol-level scoping for file:// content; and IP, host name, and proxy configuration heuristics for Intranet resources.
- Notes: local network heuristics can fail spectacularly in certain settings. Zone settings are fairly cryptic and difficult to understand. Users frequently add not-particularly-trustworthy websites to more privileged zones to work around usability problems.
- Interactions: not consistently synchronized with any other security boundaries. Largely neglects to consider the impact of cross-site scripting flaws.
Plugin access:
- Relevant to: various activities of plugin-delivered active content, which generally shares the HTTP stack, cookie jar, and document cache with the browser; and has DOM access to the embedding page.
- Security boundaries: a variety of custom, inconsistent models: for example, Java considers all content originating from the same IP as same-origin; Flash glances over redirects and considers their result same-origin with the initial URL. Most plugins also offer multiple ways to negotiate cross-domain access.
- Notes: plugin origin is derived from the URL from which the code is retrieved; Content-Type and Content-Disposition is usually ignored during this operation.
- Interactions: largely inconsistent with all other browser security mechanisms.

Operating systems are more complex and more diverse than browsers; but I dare you to come up with an example of a design nearly as messy and dangerous as this. It not just that the set of capabilities is odd, spurious, and sometimes redundant; but that each and every one of them has a slightly different understanding of who you are, and what permissions you need to be given.

The dreaded curse of openness

2011-02-01T00:09:00.000-08:00

Several weeks ago, the chairman of Trend Micro had this to say:

"Android is open-source, which means the hacker can also understand the underlying architecture and source code. We have to give credit to Apple, because they are very careful about it. It's impossible for certain types of viruses to operate on the iPhone."

Now that Kaspersky has, ahem, joined the open source crowd - I worry that hackers may soon be able to understand the operation of anti-virus software as well. And beyond that unthinkable point, only darkness looms.

CSP, HTML5, and the aesthetics of security

2011-01-22T00:00:00.001-08:00

Modern browsers are incredibly complex beasts, pushed well beyond their intended limits - and in that capacity, broken in more ways than we can imagine. We are only beginning to scratch the surface of all the design problems ahead of us - say, new and unexpected classes of UI vulnerabilities - but even within the bounds of what we understand and know how to fix, some fascinating and very human discourse patterns emerge... and will ultimately shape the future of the web.

The dominant theme of some of the security-relevant debates we are having today is that of aesthetics - an argument most prominently embodied by the controversy around Mozilla's Content Security Policy, an ambitious (and now scaled back) vision for controlling the interactions between all content on the web.

In a nutshell, many browser developers, especially those contributing actively to HTML5 security, seem to favor simplicity - and for all the good reasons, too. From their perspective, this principle brings:

Clarity of vision: the incomprehensible and practically unmanageable mess of Microsoft Internet Explorer's security zone settings serves as an important cautionary tale: trying to scratch all itches at once, and accounting for every possible corner case, can be a self-defeating design pattern - and possibly a security risk.
Ease of deployment: modest mechanisms that do not seek to redefine every aspect of browser behavior at once are much easier to implement in the browser itself, and much easier roll out and manage on application level - improving the odds of actually making a difference.
A reduced number bugs: historically, complex security features have been shown to have far more failure modes. In essence, the fewer things can be misunderstood or overlooked, the better we are all off.

On the flip side, many web application security practitioners, and a good number of Mozilla engineers, favor holistic approaches - and their reasons sound just as good:

Long-term consistency: unexpected conflicts between same-origin policy, HTTP cookies, password managers, document caching, SSL, plugins, and many other disjointed security mechanisms governing modern browsers have caused untold suffering to application developers - and still make it extremely hard to achieve certain seemingly simple goals, such as developing HTTPS-only services capable of surviving active attackers on public wifi networks.
Better support for complex use cases: it is easy to devise a way to mitigate XSS vulnerabilities for 80% of all websites on the Internet - but for a vast majority of these, XSS is not a devastating problem to begin with. If, by the virtue of being overly simplistic, the proposed solution is not suitable for the top 1,000 most sensitive destinations on the web - complex properties such as online banking, social networks, webmail interfaces - then the benefit of rolling it out is disproportionately low.

The tragedy of this debate is that it is nearly impossible to settle: both sides have valid, eloquent arguments in favor of their views. Unfortunately, pursuing different approaches for different browsers is the worst outcome of them all.

...

The second, equally interesting clash in the browser security community is that over manners: determining the proper method to solve a particular problem. Seemingly minor disagreements about peripheral detail are often at the core of competing designs and implementations: XDomainRequest versus CORS; toStaticHTML() versus *.innerStaticHTML; and many more.

In most cases, both sides of the argument make a strong case for the superiority of their vision, at least for a set of uses they care about. For example, a recent counter-proposal to CSP XSS defenses focuses on two fairly minor changes - replacing policy specifications in HTTP headers with <meta> tags; and replacing server callbacks for reporting policy violations with a DOM event handler.

The problem is, all of these approaches make quite a lot of sense:

Policy location:
- HTTP headers: more difficult to inject through common XSS vectors - therefore slightly safer.
- HTML tags: easier to place on a page when application developer has no fine-grained control over web server settings - therefore somewhat more likely to be widely embraced.
Reporting mode:
- Server-side: will not fail if policy is broken to a point of preventing any client-side code from running - more reliable, therefore less scary to deploy.
- Client-side: easier to employ when there are limitations on the server-side logging and reporting infrastructure available - more useful to developers.

Curiously, the underlying dichotomy is often false: there is no particularly strong reason why all these methods should not co-exist in a single implementation, toggled by a part of the policy itself; the argument of added complexity is often made in cases like this - but at times, it feels like a rationalization for ambitions and prior beliefs.

This is not a bad thing, to be sure - conviction and a desire to personally make an impact is what drives the open source community, and precisely what makes it so great; but that mechanism also makes it much harder to find a sensible middle ground. And if we don't find it soon - perhaps at the expense of some of our beliefs - I think it's going to haunt us all in the future... browser engineers, web application developers, and mere users alike.

Announcing cross_fuzz, a potential 0-day in circulation, and more

2011-01-01T01:58:00.000-08:00

I am happy to announce the availability of cross_fuzz - an amazingly effective but notoriously annoying cross-document DOM binding fuzzer that helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more.

The fuzzer owes much of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection mechanisms.

Detailed cross_fuzz fuzzing algorithm:

Open two windows with documents of any (DOM-enabled) type. Simple HTML, XHTML, and SVG documents are randomly selected as targets by default - although any other, possibly plugin-supported formats could be targeted instead.
Crawl DOM hierarchy of the first document, collecting encountered object references for later reuse. Visited objects and collected references are tagged using an injected property to avoid infinite recursion; a secondary blacklist is used to prevent navigating away or descending into the master window. Critically, random shuffling and recursion fanout control are used to ensure good coverage.
Repeat DOM crawl, randomly tweaking encountered object properties by setting them to a one of the previously recorded references (or, with some probability, to one of a handful of hardcoded "interesting" values).
Repeat DOM crawl, randomly calling encountered object methods. Call parameters are synthesized using collected references and "interesting" values, as noted above. If a method returns an object, its output is subsequently crawled and tweaked in a similar manner.
Randomly destroy first document using one of the several possible methods, toggle garbage collection.
Perform the same set of crawl & tweak operations for the second document, but use references collected from the first document for overwriting properties and calling methods in the second one.
Randomly destroy document windows, carry over a percentage of collected references to the next fuzzing cycle.

This design can make it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs.

I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority.

The following summarizes notification and patch status for all the affected vendors:

Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace for CVE-2011-0346) and security-relevant GUI corruption issues (XP-only, example, CVE-2011-0347). Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.
Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.
All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.
Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.
Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.
Note that with Opera, the fuzzer needs to be restarted frequently.

Well, that's it. To download the tool or see it in action, you can follow this link. The fuzzer may be trivially extended to work with any other DOM-compliant documents, plugin bindings, and so forth.

Carrot, stick, research, disclosure

2010-12-20T15:27:00.001-08:00

Several days ago, Marcia Hoffman of Electronic Frontier Foundation praised Facebook's policy on vulnerability reports - and went as far as calling it "exceptional":

"If you share details of a security issue with us and give us a reasonable period of time to respond to it before making it public, and in the course of that research made a good faith effort to avoid privacy violations, destruction of data, or interruption or degradation of our service, we will not bring any lawsuit against you or ask law enforcement to investigate you for that research."

I respect my colleagues at Facebook - but I do not think this policy deserves such praise.

The problem is that with extremely rare exceptions, software vendors do not object to being given reasonable notice about a vulnerability - but one of the most significant points of contention between them and the research community is the meaning of that single, special word: "reasonable".

Because of different incentives, businesses have a history of allowing privately reported vulnerabilities to go unresolved for a year or more; and many of the best-known names in the industry have attempted to suppress good-faith attempts to alert the public to their apparent non-responsiveness.

I suspect that Facebook is capable and willing to respond to vulnerability reports promptly, and will not resort to such tricks - but that does not make the policy sound any better. The promise not to sue people who satisfy an unspecified but vendor-defined expectation of "reasonable time" implicitly creates a threat of prosecution in non-compliant cases; and equates them to other, clearly malicious practices listed in that aforementioned paragraph.

There are interesting examples of exceptional, researcher-friendly policies out there; this one doesn't belong, yet.

Unencrypted public wifi should die

2010-12-13T22:52:00.000-08:00

Unencrypted public access wireless networks are an unbelievably harmful technology devised with no regard for the operation of the modern web - and they introduce far more problems than immediately apparent. The continued use unencrypted wifi on municipal level and in consumer-oriented settings is simply inexcusable, even if all the major websites on the Internet can be pressured into employing HTTPS-only access and Strict Transport Security by default.

Straightforward snooping and cute tricks such as sslstrip aside - all of them still deadly effective, by the way - there are many less obvious problems we simply can't solve any time soon:

Cookie poisoning: JavaScript same-origin policy draws a clear boundary between encrypted and non-encrypted content - but HTTP cookies are critically broken in this regard. It is possible to selectively overwrite secure cookies with malicious values over HTTP - with disastrous consequences for most of the contemporary web apps.
Plugin SOP problems: similarly to cookies, the variants of same-origin access rules implemented by plugins such as Java, Flash, or Silverlight, are often peculiar - and do not necessarily respect the isolation between encrypted and non-encrypted content (but share the cookie jar and document cache with the rest of the browser).
Cache poisoning: browser cache persists across network visits. On insecure wireless networks, malicious active content can be persistently cached in any non-encrypted origin - even if that origin is not intentionally visited - and will be carried onto trusted networks accessed later on (e.g., home or corporate environments); in other words, your browser may be essentially permanently backdoored after a single visit to a public hotspot. Curiously, there is some renewed interest in this area of recent. HTML5 features such as cache manifests and local storage promise to make the problem even more pronounced.
Cache retrieval: for the same reason, content injected over insecure wireless networks can comprehensively enumerate and read back all previously stored objects in browser cache, in arbitrarily selected non-encrypted origins - a huge privacy problem for as long as any remotely sensitive data is still exchanged over HTTP - even when this exchange itself happens only over private, secure networks.
Address bar autocompletion poisoning: even with mechanisms such as Strict Transport Security in place, content injected over insecure networks may attempt to silently poison address bar autocompletion mechanisms - ensuring that future attempts to navigate to a particular website will be completed in a subtly incorrect way, and will take the victim to a malicious domain name instead.

The only good way to eliminate all these risks is phasing out browser-level HTTP support altogether; but that's impractical, and simply wrong - and as much as I admire EFF, I think that universal SSL is not the right battle to fight. The burden of not decreasing user safety should rest with those introducing new standards or promoting new use cases; and something clearly went pretty awry here. We should be working hard to fix it soon - and never let it happen again.

PS. As of today, encrypted 802.11 is not much better for this use: the fiasco of WEP aside, on WPA2-PSK networks with publicly advertised key, insiders may simply decode and modify traffic to other clients by watching the handshake; while other authentication systems may be vulnerable to "Hole 196". On top of that, attackers may opt to impersonate "trusted" access points as seen fit. These shortcomings are incredibly frustrating - but can be addressed; in fact, some proprietary workarounds seem to be available already.

Firefox 3.6.13: damn you, corner cases

2010-12-09T10:47:00.000-08:00

Today's release of Firefox 3.6.13 fixes bug 602780 (CVE-2010-3774) - an interesting problem I originally reported to Mozilla in October. It's a fun one, so here's a quick recap of what it is about.

As you may recall, one of the more significant shortcomings of the same-origin policy is that it does not give any guidance on handling documents with no inherent origin associated - that is, it fails to account for all the content coming from about:, data:, file:, and similar pseudo-URLs. Consequently, early implementations of this security model simply allowed all origin-less frames or windows created by one site to be accessed freely across domains - an empty host name string equals any other empty host name string, after all. As can be expected, this approach proved to be a bad idea - and since then, quite a few necessary improvements have been made. Today, every pseudo-URL should either inherit its origin from the parent document, or be assigned a completely unique one.

Alas, in Firefox, some of this logic would not work as expected in a handful of corner cases; this problem probably traced back to a minor code refactoring somewhere in 2008. The vulnerability would not trigger with about: or data: subframes on legitimate sites - and therefore, would not affect normal browsing - but with some minimal effort, it could be leveraged by malicious sites to access and modify the contents of internal browser pages, such as about:config, about:neterror, and so forth.

The consequences of access to about:config can be disastrous, but in this case, are somewhat mitigated by the fact that under standard operating conditions, random Internet-originating content can't open that location directly. In other words, the vulnerability could not be exploited without soliciting a degree of user interaction.

The story with pages such as about:neterror is a bit more interesting, though: in modern versions of Firefox, these documents are shown in place of the old-fashioned modal dialogs to indicate navigation errors. Crucially, when this happens, the content is displayed with the intended destination URL, rather than the true origin (about:...), shown in the address bar. With this simple trick in mind, the attacker can inject his spoofed content into a window where the address bar incorrectly points to an unrelated domain of his choice. Whoops!

If you haven't upgraded to 3.6.13 yet, check out this bombastic demo to see the attack in action.

Weekend distractions: DHS threat level indicator

2010-12-03T17:16:00.000-08:00

Cool vulnerability in Firefox coming up next week. In the meantime, enjoy this project of mine:

DHS tribute threat level indicator

Yup. The name says it all.

Understanding and using skipfish

2010-11-21T13:27:00.001-08:00

Skipfish, my open source web application security scanner, is now about eight months old - and, over the course of over 70 releases, has undergone a number of substantial changes. From the very beginning, the project flirted with a number of radical ideas that are not commonly seen in this class of software - but because of this, it also proved to be deceptively easy to misuse, due to the preconceived ideas of what it could possibly offer.

So, while I maintain detailed documentation and a short troubleshooting guide, it seems appropriate to share some additional hints on how to get the most out of this tool.

A word on design goals (and what they really mean)

While skipfish tries to scratch quite a few itches, its primary goals - and the areas where it hopefully stands out - are:

Raw speed: I am constantly frustrated by the performance and memory footprint of many of the open source and commercial scanners and brute-force tools I had to work with. Skipfish tries hard to improve this - and to my knowledge, has by far the fastest HTTP and content analysis engine out there.
This does not mean that skipfish scans always take the least amount of time, compared to other tools; it simply means that I can cram a whole lot more functionality, and get much better coverage, without making the assessment unreasonably long.
In cases where the server is the bottleneck, this can obviously backfire; but when dealing with slow targets, you can configure the scanner to get a reduced coverage - roughly comparable to a more traditional tool.
Unique brute-force capabilities: the performance of the scanner allowed me to incorporate an extensive ${keyword}.${extension} brute-force functionality similar to that of DirBuster - coupled with highly customized, hand-picked dictionaries, and a unique auto-learning feature that builds an adaptive, target-specific dictionary based on site content analysis.
Most other scanners simply can't afford to let you do this in any meaningful way - and when they do, the dictionaries you can use with them are much less sophisticated, and far more request-intensive. I consider this functionality to be one of the more important assets of the tool - but you are certainly not forced to use it where impractical. The brute-force testing features are completely optional, and can be turned off to improve scan times as much as 500-fold.
High quality security checks: most scanners employ fairly naive security logic - for example, to test cross-site scripting, they may attempt injecting <script>alert(1)</script>; to detect directory traversal, they may try ../../../../../etc/passwd; and to test SQL injection, they may attempt supplying technology-specific code and look for equally technology-specific output strings.
Needless to say, all these checks have many painfully simple failure modes: the XSS check will result in a false negative when the input is partly escaped - or appears inside a HTML comment; traversal checks will fail if the application always appends a fixed extension to the input string, or is running within a chroot() jail; and SQL injection logic will break when dealing with an unfamiliar backend or an uncommon application framework.
To that effect, skipfish puts emphasis on well-crafted probes, and on testing for behavioral patterns, rather than signatures. For example, when testing for string-based SQL injection, we compare the results of passing '"original_value, \'\"original_value, and \\'\\"original_value. When the first response is similar to the third one, but different from from the second one - we can, with a pretty high confidence, say that there is an underlying query injection vulnerability (even if query results can't be observed directly). Interestingly, this check is versatile enough to do a pretty good job detecting eval()-related vulnerabilities in PHP, and injection bugs in many other non-SQL query languages.
Similarly, when probing for file inclusion, the scanner will try to compare the output of original_value, ./original_value, ../original_value, and .../original_value; if the first two cases result in similar output, and the two remaining ones result in a different outcome, we are probably dealing with a traversal problem. The redundancy helps rule out differences that can be attributed to input validation - and hey, that check also triggers on many remote file inclusion vectors in PHP.
For XSS, skipfish does depend on content analysis - but instead of the standard practice of throwing the entire XSS cheatsheet at the target, it injects a complex string that is guaranteed to break out of many different parsing modes (and much less likely to fail with crude XSS filters in place): -->">'>'", followed by a uniquely numbered tag. The unique identifier enables stored XSS detection later on, and is also interpreted in a special way inside <script> or <style> blocks.
There are many other design decisions along these lines; I believe they have a profound impact on the ability to detect real-world security problems - although paradoxically, they make the scanner perform poorly with simulated vulnerabilities in demo sites.
Coverage of more nuanced problems: most web application assessment tools simply pay no attention to the security risks caused by subtle MIME type or character set mismatches - and the awareness that these problems may lead to exploitable XSS vectors is very low within the security community.
Skipfish makes a point of noticing these and many other significant security issues usually neglected by other tools - such as caching intent mismatches, mixed content issues, XSSI, third-party scripts, cross-site request forgery, and so forth.
Quite a few people complained about "pointless" or "odd" warnings for problems thought to be non-security issues. Rest assured, most of these cases could be shown to be exploitable. When in doubt, don't hesitate to ping me for a second opinion!
Adaptive scanning for real-world applications: many scanners don't handle complex, mixed technology sites particularly well; a common headache is dealing with closely related requests being handled by different application backends with different URL semantics, error messages, or even case-sensitivity. Another hard problem is recognizing obscure 404 behaviors, unusual parameter passing conventions, redirection patterns, content duplication, and so forth. All this often requires repeated, painstaking configuration tweaks.
While skipfish certainly is not perfect - no scanner can be - the code is designed to be able to cope with these scenarios exceptionally well. This is achieved chiefly by not relying on directory, file, or error message signatures - and instead, carrying out adaptive probes for every new fuzzed location; and quickly recognizing crawl tree branches that look very much alike. While heuristics can fail in unexpected ways, I think it's of immense value.
Sleek reports with very little noise: skipfish generally does not complain about highly non-specific "vulnerabilities" commonly reported by other scanners; for example, it does not pay special attention to every non-httponly cookie, to every password form with autocomplete enabled, or to framework version or system path disclosure patterns on various pages. This means that in practice, auditors will see fewer issues in a skipfish report than in the output of most other assessment tools - and this is not a bug.
Rest assured, the interactive report produced after a scan includes summary sections where the auditor can review all password forms, cookies, and so forth if necessary - but the assumption is that human evaluation can't and should not be substituted here.

While skipfish certainly isn't perfect, these are the core properties I care about - and try to continually improve.

The most important setting: dictionary modes

The single most misunderstood - and important - feature of skipfish is its directory management model. Quite simply, getting this part wrong can easily ruin your scans.

I encourage you to have a look at the recently revamped dictionaries/README-FIRST file, which explains the basics of dictionary management in greater detail; but at the very minimum, you should be aware of the following choice:

Absolutely no brute-force: in this mode, skipfish performs an orderly crawl of the target site, and behaves similarly to other basic scanners. The mode is not recommended in most cases due to limited coverage - resources such as /admin/ or /index.php.old may not be discovered - but is blazing fast. To use it, try:
```
./skipfish -W /dev/null -LV [...other options...]
```
Lightweight brute-force: in this mode, the scanner will only try fuzzing the file name (/admin/), or the extension (/index.php.old), but never both at the same time (/backup.tgz will typically not be hit). The cost of doing so is about 1,700 requests per fuzzed location. To use this mode, try:
```
cp dictionaries/complete.wl dictionary.wl
./skipfish -W dictionary.wl -Y [...other options...]
```
This mode is the preferred way of limiting scan time where fully-fledged brute-force testing is not feasible.
Normal dictionary brute-force: in this mode, the scanner will test all the possible file name and extension pairs (i.e., /backup.tgz will be discovered, too). The mode is significantly slower, but offers superior coverage - and should be your default pick in most cases. To enable it, try:
```
cp dictionaries/minimal.wl dictionary.wl
./skipfish -W dictionary.wl [...other options...]
```
The cost of this mode is about 50,000 requests per fuzzed location. You can replace minimal.wl with medium.wl or complete.wl for even better coverage, but at the expense of a 2x to 3x increase in scan time; see dictionaries/README-FIRST for an explanation of the difference between these files.

Other options you need to know about

Skipfish requires relatively little configuration, but rest assured, is not a point-and-click tool. You should definitely review the documentation to understand the operation of rudimentary options such as -C (use cookie authentication), -I (only crawl matching URLs), -X (exclude matching URLs), -D (define domain scope), -m (limit simultaneous connections), and so forth.

Here is a list of some of the more useful but under-appreciated options that you should consider using in your work:

Limit crawl tree fanout: options -c (immediate children limit) and -x (total descendant limit) allow you to fine-tune scan coverage for very large sites where -I and -X options are impractical to use. Non-deterministic crawl probability setting (-p) may also be helpful there.
More SSL checks: some sites care about getting SSL right; specify -M to warn about dangerous mixed content scenarios and insecure password forms.
Spoof another browser: use -b to convincingly pretend to be MSIE, Firefox, or an iPhone. This option does not merely change the User-Agent string, but also ensures that other headers have the right syntax and ordering.
Do not accept new cookies: on cookie-authenticated sites that do not maintain session state on server side, accidental logout can be prevented without the need to carefully specify -X locations: adding -N simply instructs skipfish to ignore all attempts to delete or modify -C cookies.
Trust another domain: skipfish complains about dangerous script inclusion and content embedding from third-party domains, and can optionally warn you about outgoing links. To minimize noise, use -B to identify any domains you trust, and therefore, want to exclude from these checks.
Reduce memory footprint: to generate scan reports, the scanner keeps samples of all retrieved documents in memory. On some large, multimedia-heavy sites, this may consume a lot of RAM. In these cases, -e may be used to purge binary (non-ASCII) content without impacting report quality appreciably.
Be dumb: by specifying -O, skipfish can be instructed not to analyze returned HTML to extract links - turning it into a fast, purely brute-force tool.

Troubleshooting

Skipfish has bugs, there are features yet to be implemented, and web frameworks it hasn't encountered yet. When you run into any trouble, please check out this doc, but also do not hesitate to ping me directly. Your feedback is the only way this tool can be improved.

These are not the events you are looking for

2010-11-01T20:53:00.000-07:00

Yeah, so this probably should not be possible.

The underlying problem is pretty cute: most browsers can be programatically prevented from dequeuing and processing UI events delivered by the operating system; canonical examples involve using busy JavaScript loops, blocking XMLHttpRequest calls, and particularly complex HTML or XML documents.

Upon leaving this state, the queued events may not be properly purged, and may end up getting delivered to an incorrect and unexpected context - possibly carrying out an undesirable action in another domain, or interacting with browser chrome.

I filed bug 608899 for this particular demo in Firefox - but given the general, cross-browser state of disrepair when it comes to UI timing and related attacks, I am not getting my hopes up.

HTTP cookies, or how not to design protocols

2010-10-28T18:54:00.000-07:00

For as long as I remember, HTTP cookies have been vilified as a grave threat to the privacy of online browsing; wrongly so. That said, the mechanism itself is a very interesting cautionary tale for security engineers - and that will be the theme of today's feature.

Cookies were devised by Lou Montulli, a Netscape engineer, somewhere in 1994. Lou outlined his original design in a minimalistic, four-page proposal posted on netscape.com; based on that specification, the implementation shipped in their browser several months later - and other vendors were quick to follow.

It wasn't until 1997 that the first reasonably detailed specification of the mechanism has been attempted: RFC 2109. The document captured some of the status quo - but confusingly, also tried to tweak the design, an effort that proved to be completely unsuccessful; for example, contrary to what is implied by this RFC, most browsers do not support multiple comma-delimited NAME=VALUE pairs in a single Set-Cookie header; do not recognize quoted-string cookie values; and do not use max-age to determine cookie lifetime.

Three years later, another, somewhat better structured effort to redesign cookies - RFC 2965 - proved to be equally futile. Meanwhile, browser vendors tweaked or extended the scheme in their own ways: for example, around 2002, Microsoft unilaterally proposed httponly cookies as a security mechanism to slightly mitigate the impact of cross-site scripting flaws - a concept quickly, if prematurely, embraced by the security community.

All these moves led to a very interesting situation: there is simply no accurate, official account of cookie behavior in modern browsers; the two relevant RFCs, often cited by people arguing on the Internet, are completely out of touch with reality. This forces developers to discover compatible behaviors by trial and error - and makes it an exciting gamble to build security systems around cookies in the first place.

In any case - well-documented or not, cookies emerged as the canonical solution to an increasingly pressing problem of session management; and as web applications have grown more complex and more sensitive, the humble cookie caught the world by storm. With it, came a flurry of fascinating security flaws.

They have Internet over there, too?

Perhaps the most striking issue - and an early sign of trouble - is the problem of domain scoping.

Unlike the more pragmatic approach employed for JavaScript DOM access, cookies can be set for any domain of which the setter is a member - say, foo.example.com is meant to be able to set a cookie for *.example.com. On the other hand, allowing example1.com to set cookies for example2.com is clearly undesirable, as it allows a variety of sneaky attacks: denial of service at best, and altering site preferences, modifying carts, or stealing personal data at worst.

To that effect, the RFC provided this elegant but blissfully naive advice:

"Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".

Regrettably, there are at least three glaring problems with this scheme - two of which should have been obvious right away:

Some country-level registrars indeed mirror the top-level hierarchy (e.g. example.co.uk), in which case the three-period rule makes sense; but many others allow direct registrations (e.g., example.fr), or permit both approaches to coexist (say, example.jp and example.co.jp). In the end, the three-period rule managed to break cookies in a significant number of ccTLDs - and consequently, most implementations (Netscape included) largely disregarded the advice. Yup, that's right - as a result, you could set cookies for *.com.pl.
The RFC missed the fact that websites are reachable by means other than their canonical DNS names; in particular, the rule permitted a website at http://1.2.3.4/ to set cookies for *.3.4, or a website at http://example.com.pl./ to set a cookie for *.com.pl.
To add insult to injury, Internet Assigned Numbers Authority eventually decided to roll out a wide range of new top-level domains, such as .biz, .info, or .jobs - and is now attempting to allow arbitrary gTLD registrations. This last step promises to be a yet another nail to the coffin of sane cookie management implementations.

Net effect? All mainstream browsers had a history of embarrassing bugs in this area - and now ship with a giant, hairy, and frequently-updated lists of real-world "public suffix" domains for which cookies should not be set - as well as an array of checks to exclude non-FQDN, IPs, and pathological DNS notations of all sorts.

8K ought to be enough for for anybody

To make denial-of-service attacks a bit harder, it is well-understood that most web servers limit the size of a request they are willing to process; these limits are very modest - for example, Apache rejects request headers over 8 kB, while IIS draws the line at 16 kB. This is perfectly fine under normal operating conditions - but can be easily exceeded when the browser is attempting to construct a request with a lot of previously set cookies attached.

The specification neglected this possibility, offered no warning to implementators, and proposed no discovery and resolution algorithm. In fact, it mandated minimal jar size requirements well in excess of the limits enforced by HTTP servers:

"In general, user agents' cookie support should have no fixed limits. They should strive to store as many frequently-used cookies as possible. Furthermore, general-use user agents should provide each of the following minimum capabilities [...]:

* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the size of the characters that comprise the cookie non-terminal in the syntax description of the Set-Cookie header)
* at least 20 cookies per unique host or domain name"

As should be apparent, the suggested minimum - 20 cookies of 4096 bytes each - allows HTTP request headers to balloon up to the 80 kB boundary.

Does this matter from the security perspective? At first sight, no - but this is only until you realize that there are quite a few popular sites that rely on user-name.example.com content compartmentalization; and that any malicious user can set top-level cookies to prevent the visitor from ever being able to access any *.example.com site again.

The only recourse domain owners have in this case is to request their site to be added to the aforementioned public suffix list; there are quite a few entries along these lines there already, including operaunite.com or appspot.com - but this approach obviously does not scale particularly well. The list is also not supported by all existing browsers, and not mandated in any way for new implementations.

"Oh, please. Nobody is actually going to depend on them."

In the RFC 2109 paragraph cited earlier, the specification pragmatically acknowledged that implementations will be forced to limit cookie jar sizes - and then, confusingly demanded that no fixed limits are put in place, yet specified minimum limits that should be obeyed by implementators.

What proved to be missing is any advice on a robust jar pruning algorithm, or even a brief discussion of the security considerations associated with this process; any implementation that enforces the recommended minimums - 300 cookies globally, 20 cookies per unique host name - is clearly vulnerable to a trivial denial-of-service attack: the attacker may use wildcard DNS entries (a.example.com, b.example.com, ...), or even just a couple of throw-away domains, to exhaust the global limit, and have all sensitive cookies purged - kicking the user out of any web applications he is currently logged into. Whoops.

It is worth noting that given proper warning, browser vendors would not find it significantly more complicated to structure the limits differently, enforce them on functional domain level, or implement pruning strategies other than FIFO (e.g., taking cookie use counters into account). Convincing them to make these changes now is more difficult.

While the ability to trash your cookie jar is perhaps not a big deal - or rather, the ability for sites to behave disruptively is also poorly mitigated on HTML or JavaScript level, making this a boring topic - the weakness has special consequences in certain contexts; see next section for more.

Be my very special cookie

Two special types of HTTP cookies are supported by all contemporary web browsers: secure, sent only on HTTPS navigation (protecting the cookie from being leaked to or interfered by rogue proxies); and httponly, exposed only to HTTP servers, but not visible to JavaScript (protecting the cookie against cross-site scripting flaws).

Although these ideas appear to be straightforward, the way they were specified implicitly allowed a number of unintended possibilities - all of which, predictably, plagued web browsers through the years. Consider the following questions:

Should JavaScript be able to set httponly cookies via document.cookie?
Should non-encrypted pages be able to set secure cookies?
Should browsers hide jar-stored httponly cookies from APIs offered to plugins such as Flash or Java?
Should browsers hide httponly Set-Cookie headers in server responses shared with XMLHttpRequest, Flash, or Java?
Should it be possible to drop httponly or secure cookies by overflowing the "plain" cookie jar in the same domain, then replace them with vanilla lookalikes?
Should it be possible to drop httponly or secure cookies by setting tons of httponly or secure in other domains?

All of this is formally permitted - and some of the aforementioned problems are prevalent to this day, and likely will not be fixed any time soon.

At first sight, the list may appear inconsequential - but these weaknesses have profound consequences for web application design in certain environments. One striking example is rolling out HTTPS-only services that are intended to withstand rogue, active attackers on open wireless networks: if secure cookies can be injected on easy-to-intercept HTTP pages, it suddenly gets a whole lot harder.

If it tastes good, who cares where it comes from?

Cookies diverge from JavaScript same-origin model in two fairly important and inexplicable ways:

domain= scoping is significantly more relaxed than SOP, paying no attention to protocol, port number, or exact host name. This undermines the SOP-derived security model in many compartmentalized applications that also use cookie authentication. The approach also makes it unclear how to handle document.cookie access from non-HTTP URLs - historically leading to quite a few fascinating browser bugs (set location.host while on a data: page and profit!).
path= scoping is considerably stricter than what's offered by SOP - and therefore, it is completely useless from the security standpoint. Web developers misled by this mechanism often mistakenly rely on it for security compartmentalization; heck, even reputable security consultants get it completely wrong.

On top of this somewhat odd scoping scheme, conflict resolution is essentially ignored in the specification; every cookie is identified by a name-domain-path tuple, allowing identically named but differently scoped cookies to coexist and apply to the same request - but the standard fails to provide servers with any metadata to assist in resolving such conflicts, and does not even mandate any particular ordering of such cookies.

This omission adds another interesting twist to the httponly and secure cookie cases; consider these two cookies:

Set on https://www.example.com/:
  FOO=legitimate_value; secure; domain=www.example.com; path=/

Set on http://www.example.com/:
  FOO=injected_over_http; domain=.example.com; path=/

The two cookies are considered distinct, so any browser-level mechanisms that limits attacker's ability to clobber secure cookies will not kick in. Instead, the server will at best receive both FOO values in a single Cookie header, their ordering dependent on the browser and essentially unpredictable (and at worst, the cookies will get clobbered - a problem in Internet Explorer). What next?

Character set murder mystery

HTTP/1.0 RFC technically allowed high-bit characters in HTTP headers without further qualification; HTTP/1.1 RFC later disallowed them. Neither of these documents provided any guidance on how such characters should be handled when encountered, though: rejected, transcoded to 7-bit, treated as ISO-8859-1, as UTF-8, or perhaps treated in some other way.

The specification for cookies further aggravated this problem, cryptically stating:

"If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required."

There is an obvious problem with saying that you can use certain characters, but that their meaning is undefined; the systemic neglect of this topic has profound consequences in two common cases where user-controlled values frequently appear in HTTP headers: Content-Disposition is one (eventually "solved" with browser-specific escaping schemes); another is, of course, the Cookie header.

As can be expected, based on such poor advice, implementators ended up with the least sensible approach; for example, I have a two-year-old bug with Mozilla (418394): the problem is that Firefox has a tendency to mangle high-bit values in HTTP cookies, permitting cookie separators (";") to suddenly materialize in place of UTF-8 in the middle of an otherwise sanitized cookie value; this led to more than one web application vulnerability to date.

A session is forever

The last problem I want to mention in this post is far less pressing - but is also an interesting testament to the shortcomings of the original design.

For some reason, presumably due to privacy concerns, the specification decided to distinguish between session cookies, meant to be non-persistent; and cookies with a specified expiration date, which may persist across browser sessions, are stored on the disk, and may be subject to additional client-enforced restrictions. On the topic of the longevity of the former class of cookies, the RFC conveniently says:

"Each session is relatively short-lived."

Today, however, this is obviously not true, and the distinction feels misguided: with the emergence on portable computers with suspend functionality, and the increased shift toward web-oriented computing, users tend to keep browsers open for weeks or months at a time; session cookies may also be stored and then recovered across auto-updates or software crashes, allowing them to live almost indefinitely.

When session cookies routinely persist longer than many definite-expiry ones, and yet are used as a more secure and less privacy-invasive alternative, we obviously have a problem. We probably need to rethink the concept - and either ditch them altogether, or impose reasonable no-use time limits at which such cookies are evicted from the cookie jar.

Closing words

I find it quite captivating to see the number of subtle problems caused by such a simple and a seemingly harmless scheme. It is also depressing how poorly documented and fragile the design remains some 15 years later; and that the introduction of well-intentioned security mechanisms, such as httponly, only contributed to the misery. An IETF effort to document and clarify some of the security-critical aspects of the mechanism is underway only now - but it won't be able to fix them all.

Some of the telltale design patterns - rapid deployment of poorly specified features, or leaving essential security considerations as "out of scope" - are still prevalent today in the browser world, and can be seen in the ongoing HTML5 work. Hopefully, that's where the similarities will end.

Attack of the monster frames (a mini-retrospective)

2010-10-14T20:51:00.000-07:00

Some 15 years ago, the introduction of HTML frames caused a significant uproar in the (still young) web development community. The outraged purists asserted that frames were bound to ruin everything: incompatible with many of the browsers and search engines of the old; bringing a significant potential to break navigation or printing; unfamiliar and confusing to users; and simply against the original vision supposedly laid out by the founding fathers of the web.

Today, these criticisms seem rather arbitrary: although framed navigation had its share of amusing missteps (not any worse than most other HTML features, I'd argue), the frames have become an important and unobtrusive part of the modern web, and a valuable content compartmentalization tool. But shockingly, even if for all the wrong reasons, the original detractors had one thing right: in a sense, they turned out to be our doom.

How so? Recall that framed browsing dates back to the days of the web being a simple tool for distributing static content - and in that context, the technology warranted no special consideration from the security community; but as our browsers morphed into de facto operating systems for increasingly complex, dynamic applications - well, we quickly discovered that the ability to selectively embed fully functional, third-party content on unrelated and potentially malicious websites is pretty bad news.

One of the earliest problems - with early reports dating back to at least 2004, and variants still being discovered several years later - is the realization that frames are implemented using essentially the same model as standalone windows; this model allows any website in possession of window name (or its DOM handle) to navigate it at will. This property is mostly harmless when dealing with proper windows equipped with an address bar - but is a disaster for seamlessly framed regions on trusted websites: if malicious-site.com can open trusted-application.com in a new window, and then navigate that application's frames to any other location - it can, essentially, silently hijack the UI.

Following this discovery, Adam Barth and others spent a fair amount of time proposing a better approach, and convincing several browser vendors to implement it; but even today, certain unavoidable weaknesses in this model prevail.

The next notable milestone: clickjacking - a seemingly obvious threat essentially ignored by the security community (perhaps in hope it disappears), until extravagantly publicized by Jeremiah Grossman and Robert 'RSnake' Hansen in 2008. The idea behind the attack is simple: if a frame containing trusted-application.com is placed on malicious-site.com, and then partly obscured or made transparent - the user can be easily tricked into thinking he is interacting with the UI of malicious-site.com - but end up sending the UI event to trusted-application.com, instead.

As the name implies, their analysis focused on mouse clicks - which in a sense, did the attack some disservice: the reporting led the community to assume that only certain exceedingly simple UI actions (such as the "like" buttons on social networking sites) could be realistically targeted - and that the attacker would still be facing difficulties computing the right alignment of visual elements for all targeted systems, browsers, and screen resolutions. But that's simply not true.

To demonstrate other perils of cross-domain frames, I posted a proof-of-concept exploit for an attack I jokingly dubbed strokejacking - showing that with the use of onkeydown events, selective keystroke redirection across domains can be used to perform very complex UI actions in the targeted application, far beyond what is possible with clickjacking alone. I also discussed reverse strokejacking - an even more depressing variant where evil embeddable gadgets on a targeted site are able silently intercept user input by playing with the focus() method. These reports received very little attention - but given the ridiculous name, that's perhaps for the best.

Since then, the situation with framed content has gotten even worse: not long ago, we witnessed this presentation from Paul Stone. Paul discussed drag-and-drop attacks on third-party frames: text selected in one obscured frame pointing to trusted-application.com could be unintentionally dragged and dropped into the area controlled by malicious-site.com - thus revealing the content across domains. Many researchers and browser vendors summarily dismissed this threat, on the grounds that the necessary interactions must complex and unusual - for example, triple-clicking or pressing Ctrl-A to select text - and therefore, that they are difficult to solicit; but this is incorrect.

What have we missed, then? Paul casually mentioned one special type of a common UI interaction we all frequently engage in on even the least interesting sites: using the scroll bar. Note that the act of grabbing the slider, dragging it down, and releasing it... is eerily similar to the act of selecting text, or dragging and dropping a selection across the page. The attack can be modified thus:

Create a page with an article that spans more than a single screen - or has a TEXTAREA with an EULA that needs to be scrolled to the end before the "I agree" button is enabled, instead.
Have a transparent IFRAME pointing to trusted-application.com that follows the mouse pointer.
As soon as the user clicks the slider and holds the mouse button, reposition the frame up in relation to the cursor. This ensures that the entire framed text is selected, regardless of mouse movement (yes, this works!).
Wait for mouse button to be released.
Reposition the frame so that the next click will begin to drag the selection.
While the user is interacting with the slider, move the frame away, and place a receiving TEXTAREA or contentEditable / designMode container under the mouse pointer.
Steal documents across domains!

There are some technical challenges that make this a bit more complicated than advertised - but these can be worked around in a majority of the browsers on the market.

In the end, cross-domain frames proved to be a giant and completely unexpected attack surface; and very depressingly, we still have no idea how to properly address the problem once and for all. There simply are no simple and elegant solutions compatible with the modern web; and rest assured, browser vendors are extremely hesitant to experiment with complex heuristics instead. The only thing we decided to do to tackle the general threat is plastering the holes over with X-Frame-Options - a naive opt-in mechanism that allows websites to refuse being framed across domains. Alas, this mechanism will never be used by all the sites that actually need it - and it offers no protection in more complex cases, such as the increasingly prevalent embeddable gadgets.

The history of information security is littered with disturbingly similar cases of browser features colliding with each other, or being incompatible with the natural evolution of the web. If you need another example, just look at the profound problems caused by differences between same-origin policies for JavaScript, cookies, plugins (Java in particular) - and for peripheral browser features, such as password managers.

Because of this, I often fear that we are bound to repeat the painful security lessons of framed browsing very soon; for example, I am simply intimidated by the rush to deploy some of the more complex and at times exotic features as a part of HTML5 - web sockets, workers, sandboxing, storage, application caches, notifications, CORS, UMP, and countless other new HTML, CSS, and JS extensions added there every other week.

Yes, it's called "job security". But at times, it tends to suck.

PS. Yes, yes, I know. Interesting bugs coming soon. I have a very cool and major fuzzer waiting to be released, but I am still waiting for all vendors to fix the outstanding issues. Neat Firefox SOP bug is coming soon, too.

Off-topic: concise electronics for geeks

2010-10-05T15:55:00.001-07:00

I always find it disappointing that so many of my extremely bright peers have only a vague idea about the inner workings of electronic circuits - and therefore, of modern computers. I think that all too often, this is a significant if underappreciated handicap.

The web today is chock-full of hobbyist guides - but most of them resort to gross oversimplification (such as the initially useful, but ultimately misleading hydraulic analogies), or are simply very inaccurate and incomplete. The remaining few websites I know of tend to resort to mundane, academic rigor - complete with differential equations and complex number algebra for transient analysis. These concepts are highly unlikely to be accessible, or even that useful, in hobbyist work.

I'm hoping to bridge this gap with my "Concise electronics for geeks", a reasonably short but anatomically correct primer on the physical phenomena, and practical considerations, in analog and digital circuits.

Feedback welcome!

The rise and fall of perfect security

2010-09-14T12:37:00.000-07:00

Modern societies, however resilient, are built on remarkably shaky foundations: every single day, we all depend on the moral standards and the restraint of thousands of random strangers. The rules of this game are weakly enforced through series of very imperfect deterrence mechanisms (less than 20% of all property crime is ever solved in the United States) - but in the end, our world is little more than an incredibly elaborate honor system that we all voluntarily participate in.

That's probably okay - we are programmed to play along, and this approach proved to be a smart evolutionary move. A degree of trust is essential to advancing our civilization at a reasonable pace; and paradoxically, despite the apparent weaknessess, the accelerated rate of progress makes us stronger and more adaptable as a species in the long run.

When it comes to the online existence, our attitudes seem drastically different, though: we only joke about the idea of using the evil bit - and yet, we are perfectly comfortable that the locks on our doors can be opened with a safety pin. We scorn web developers who can't seem to be able to get input validation right - even though we certainly don't test our morning coffee for laxatives or LSD. We are being irrational - but why?

Perhaps the reason is simple: the mankind had thousands of years to work out the rules for social interactions in the real world; societies collapsed, new ones emerged - with an increasingly complex system of moral values passed from one generation to another. The Internet is much younger in comparison, and in the end, very different from what we are accustomed to: your neighbor will not try to sneak into your house, but may have far fewer qualms about using your wireless network - a concept that feels much less like a crime. He will not condone theft - but likely feels ambivalent about making unlawful copies of digital content. He may frown upon crude graffiti - but just chuckle at the sight of exploited persistent XSS on a popular website.

An argument can be made that the incentives in online interactions are so different from these in the physical realm, that any such comparisons are simply inappropriate. But then, consider Wikipedia - a design that stands against everything we know about information security, yet demonstrates remarkable resilience in the face of attacks.

Here's a perverse thought, then: what if our pursuit of perfection in information security stems from a fundamental misunderstanding of how human communities can emerge and flourish? We are essentially preaching a model of a society based on complete distrust - but as the complexity of the online world approaches that of real life, the odds of being able to design perfectly secure software are rapidly diminishing; and the impact of being so paranoid is already taking its toll on how much we can achieve today.

If this model is not sustainable, will our online world share the fate of many other early civilizations - collapsing under the weight of its own imperfections, and ultimately, going the way of the dinosaur?

Perhaps; if so - new, more enlightened communities will certainly emerge.

Barbers and security professionals

2010-09-01T13:12:00.001-07:00

There seems to be a significant, government-sponsored push for compulsory certification and licensing in the security industry. The wonderfully self-contradictory report from the Commission on Cybersecurity aside, Larry Seltzer pointed out that this very idea is also a major part of the proposed Cybersecurity Act of 2009:

"Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any [...] information system or network designated by the President, or the President’s designee, as a critical infrastructure information system or network, who is not licensed and certified under the program."

I agree that there are persuasive arguments to be made in favor of taking this step - but it is very important to recognize that the same arguments can easily be made in favor of mandatory licensing for almost any contemporary profession. Quite simply: in modern societies, people serving even the most mundane roles can and occasionally do cause profound losses or significant distress to others. C'est la vie.

There is a small subset of professions where the stakes are particularly high - for example, building engineers; and several classes of occupations endowed with unique social privileges or an unusual degree of trust - say, doctors, lawyers, or teachers. In all these cases, licensing probably makes sense - although quite literally, it comes at a very significant price.

In most other occupations, however, the situation is far less obvious - and the current regulatory practice is rather arbitrary. We usually license barbers and hot-dog vendors - but not bakers, farmers, or pacemaker assembly line workers. Electricians and plumbers are licensed - but construction workers do not need to demonstrate even basic competency to any external body. Louisiana has a tough test and mandatory licensing for florists. Many of these distinctions are driven by specific interest groups, some are fueled by moral panics; but they do not seem to form a coherent, cost-efficient plan to make our society a safer place.

The extra cost of licensing aside, the most significant pitfall of overzealous regulation is that in attempts to preemptively police complex industries or individual human behaviors, governments are necessarily clumsy and heavy-handed - and often fail to consider many of the socially valuable corner cases. Here's a couple of my favorite (if only vaguely related) non-IT anecdotes:

To combat the proliferation of basement meth labs, Texas requires a license and a home inspection to buy a beaker. While this is unlikely to have any impact on real criminal activity, teaching your children chemistry suddenly gets a lot more complicated.
In an attempt to curtail drug use, eleven US states require you to have a prescription to buy syringes. This has a significant impact on many types of precision hobbies, where syringes are indispensable as a measuring tool; and probably only promotes syringe reuse among drug addicts.
Following reports of people pointing lasers at aircrafts, Australia and some other jurisdictions ban sale or import of lasers with output over 1 mW. This rule also covers more powerful but completely eye-safe lasers with integral pattern-generating optics - commonly used in machine vision and hobbyist robotics; the impact on these applications is profound.

In the end, it is a natural human instinct to try and minimize many of the perceived risks we are subjected to - but it's also important to seek sensible balance between this goal, and the task of maintaining our civil liberties, or enabling scientific progress. We can make our lives resemble one giant TSA checkpoint - but it's not a cheering prospect to contemplate.

So, yup: it is clear that bad software engineering may lead to real damage, and that the current situation is far from being perfect. There is also a potential for damage in getting a bad haircut, or being served a mystery hot-dog. In the end, however, I believe that in absence of truly exceptional circumstances and profound social benefits, we should be giving people the right to choose - and leave it to the industry to come up with the sort of meaningful professional certifications that it actually needs (if it needs any). Rudimentary liability for negligent engineering may be a far better method of improving status quo, by creating incentives to care about security - rather than having a certification system to hide behind.

Some of the urgency around this topic is fueled today by the end-times rhetoric about cyber-terrorism, cyber-warfare, and the imminent cyber-apocalypse - and the apparent shortage of qualified personnel to step up and save the day; but for most part, I do think this idea is very misguided. The landscape of information security, and the economics of vulnerability exploitation, have not fundamentally changed in the past 6-8 years or so - spare for a body of vivid anecdotes, and a couple of interesting but not surprising incidents; we also enjoyed a steady growth of a competent workforce, and a very self-limiting problem of charlatans. It is still the bored teenagers and the crazy geeks, and not the XSS-obsessed arm of Al Qaeda, that are the most significant threat to our infrastructure. True, government agencies are finding it unexpectedly difficult to hire the right talent, but some of the reasons for this may lie with the organizational challenges these entities are facing today - and not with the failings of the outside world.

...

Even if you disagree with the vaguely libertarian premise outlined earlier - that governments should not regulate professions in absence of exceptional social benefits of doing so - the other important question is whether there exists a body of stable, scientific knowledge that could be enforced as a part of a professional licensing scheme; if not, then the entire philosophical argument is moot. The apparent failure of commercial certifications systems - a fact confusingly pointed out and then subsequently completely ignored in the CSIS report - may offer an important clue: are the existing schemes inadequate and weakly embraced simply because people who administer them are incompetent quacks? If not, then perhaps, something more profound is amiss - and a new, shiny licensing scheme is not going to change that.

"Permission to cyber, sir!"

2010-08-31T14:41:00.000-07:00

Center for Strategic and International Studies, Commission on Cybersecurity for the 44th Presidency:

"It is the consensus of the Commission that the current professional certification regime is not merely inadequate; it creates a dangerously false sense of security."

...and therefore:

"What has evolved in medicine over the last century is a system that recognizes that different kinds of skills and specialties are required. And, since most of us are not able to access [sic] the qualifications of a practitioner when a need arises, we now have an education system with accreditation standards and professional certifications by specialty. We can afford no less in the world of cyber."

The folks who refer to IT as "the world of cyber" with a straight face, hope to be instrumental in establishing a federally-managed security accreditation program administered by the Board of Information Security Examiners - a program with aspirations to become a mandatory licensing system in the not-so-distant future:

"Medicine has addressed the need for more specialized professional certifications under a regime overseen by the American Board of Medical Specialties (http://www.abms.org). Board certifications, rigorously administered and overseen, provide important information about the skills and knowledge of practitioners to the purchaser of medical services.

Similarly, it is essential to assure that those who buy cybersecurity services have tools to evaluate the competence of those whom they engage."

The existing systems have failed, they conclude - and the one now proposed will be very different, for reasons not elaborated upon (beyond, curiously, introducing a "tough educational component"). To arrive at a meaningful solution, it is suggested to partner with, and learn from, (ISC)², ISACA, and the SANS Institute.

A new, standardized taxonomy for information security occupations is also given in the whitepaper. Certifications from the aforementioned organizations are named as the recommended credentials for the normalized roles.

I'm sure there is a set of tubes where this reasoning makes perfect sense. In my set of tubes, it sure is pretty scary.

Commercial web scanners and the word "suck"

2010-08-20T18:21:00.001-07:00

I had an interesting debate on a public mailing list today. It might have started with me casually claiming that commercial scanners are "sucky" - and escalated with both the former CTO of SPI Dynamics and the former director of Watchfire essentially calling me a moron. Their take is fair and probably accurate - but this particular argument is perhaps interesting enough to capture it here in a more coherent form.

Let's begin with a relatively uncontroversial observation: we simply don't know how to build decent web application scanners today - be it in the commercial or the open source world. How bad is the issue? Consider that the following topics essentially remain the Millenium Prize Problems in this field:

Deciding whether two HTTP responses seen at two different URLs functionally correspond to the same component. Many unrelated pages look very much alike, because of the heavy use of headers, footers, and other templates. Conversely, a single page may change appearance every time it is requested if the content is generated dynamically. Pretty much every single fuzzy matching algorithm used here has spectacular and common failure modes.
Deciding what constitutes "page not found" and "error occurred" responses for various parts of the website, a prerequisite for a crawl. This task gets particularly interesting when various URLs are mapped to several different back-end frameworks, a common scenario in enterprise settings; in some of these cases, HTTP response codes are not passed through to the end user, too.
Figuring out how the application encodes query parameters and interprets URL paths. Surprisingly, even the most respected and largest enterprise vendors - say, SAP or Oracle - often treat RFCs as a friendly suggestion at best, and invent their own, outlandish conventions for no apparent reason. Throw mod_rewrite into the mix, and things get seriously hairy.
Telling whether a particular security attack probe succeeded at all. Consider testing for a buffer overflow: both a successful attack on a vulnerable code, and tripping a security exception due to a well-implemented parameter length check, may result in an identical HTTP 500 response. What next?

The list goes on. In the end, automated scanners very often fare poorly when it comes to finding security bugs: they consistently fail to reach or properly recognize all the low-hanging fruit, spew out significant amounts of false positives - and just as often, simply catch fire when attempting to crawl a site in the first place.

This does not mean that web application scanners are worthless; but their primary value lies in equipping a skilled, human pentester with the initial view of the structure of a site; and automating certain cumbersome tasks, such as the execution of brute-force attacks. The reality is harsh: without the right person behind the wheel, the output of such a scanner, no matter how well tabulated and color-coded, tells you next to nothing about how secure your infrastructure is.

Regrettably, skilled pentesters with in-depth vulnerability hunting expertise, and excellent insight into how the web actually works, are exceptionally hard to get; heck, they are even difficult to recognize: there are no meaningful certifications, no particularly useful professional bodies... and even an impressive employment history or a history of conference presentations is a hit-and-miss indicator.

As a result, many commercial entities end up without the low-level security expertise needed to truly benefit from running a web security scanner - and in absence of this, they unrealistically expect the tool to give them some sort of a turn-key insight into the unknown. This never works as expected; and with nobody equipped to reliably evaluate the quality of the crawl, or the accuracy and ingenuity of the probes used, there is not even a proper feedback loop.

The problems the customers have here reflect negatively on the vendors, too: the company eventually accumulates a baggage of institutional customers who do not exert any pressure on improving the products to - let's say - always have cutting-edge SQL injection checks; and heavily focus on more easily verifiable, but peripheral functionality, instead: plug-and-play support for all sorts of internal SSO systems, elaborate reporting capabilities, compliance-related views that can be shown as a proof of due diligence, and so forth. All these features have some value, of course - but ultimately, they divert resources from the one pursuit that matters the most: helping a skilled pentester, and getting better at it.

In this sense, the commercial vulnerability scanner market is, by large, driven by pathological incentives - and will probably remain this way, at least until enough skilled professionals enter the workforce, or - less likely - until a major technological breakthrough is made.

Now, here's an interesting tidbit: have a look at the open-source vulnerability scanner world. Almost all the web application scanning tools that cropped up in the past two years are written by active bug hunters who use these tools in their day to day work, and were unhappy with what commercial tools have to offer. Not all of these alternatives are good, and not all will succeed - but they are developed with a very important goal in mind: to get really good at spotting bugs, and nothing more. Many of them already surpass some of the more stagnant commercial offerings in this department - and the improvement will continue.

I am very reluctant to make sweeping statements about the superiority of one software development model over another - but in this case, it seems to make a real difference, at least today. And, sure, I recognize that this argument goes both ways: the moment those open source developers start deriving most of their income from selling their products, rather than from consulting services, many of the tools will (as one person put it) quickly begin to suck.

Don't let facts get in the way of writing

2010-08-17T15:06:00.001-07:00

There are only two things I know about a company called Armorize; the first thing is that they have a nice website. The other is that they apparently employ Aditya K. Sood - a researcher I recall from BUGTRAQ and elsewhere, prominent for having a long track record of highly dubious vulnerability research. This post isn't about him or the company, though - and rather, about a puzzling chain of events they set in motion yesterday.

You see, yesterday, a cryptically titled post, "IFrames and URL Stringency", appeared on their official blog. I am quoting one of the key paragraphs here:

"The URL obfuscation is a big stringency in the online world. Actually, it tests the browser efficiency to dissect the behavior of crafted URL. That has to be done. The browsers have shown falsified behavior in determining the source and destination of URL's when it is obfuscated or fused with meta characters. This is dangerous from a user perspective because a victim can go to undesired destination. Well, lot of changes have been noticed in browser development with respect to that but in certain conditions , browsers still fail to find the authentic nature of URL's being rendered in the browser."

The nearly incomprehensible post reminds me of the writings of Gene Ray - but thankfully, it eventually references Mozilla bug 570658. From this bug, it quickly becomes evident that the problem is a wonderful non-issue - and this should be apparent to any layperson willing to actually try and understand the alleged flaw.

In essence, several years ago, Firefox opted to display a warning when the top-level document is navigated to URLs that happen to contain embedded HTTP authentication credentials. They did this to combat the surge of phishing attacks against non-technical audiences, using misleading URLs such as:

http://www.paypal.com@www.evil.com/

While the decision to cripple HTTP authentication is somewhat contentious, the step clearly has some merit: the more RFCs you need to read to understand the contents of the address bar, the less likely you are to get it right.

Aditya's complaint in the aforementioned bug is very simple, and boils down to the observation that Firefox employs this warning only for the top-level document - but does not apply this logic to subresources such as IFRAMEs. If you think about it for five seconds or so, it's painfully evident why: there is simply no need to do so. The URLs of these subresources are never displayed in the address bar, and therefore, there is no opportunity to confuse the user in any way. There is no reasonable attack scenario where this would matter. It's common sense, too: you don't need to be able to tell a buffer overflow from a format string vulnerability to understand why.

That's where the story should end. It did not:

It's nice that some of these stories eventually included a rebuttal from Mozilla. They should never have seen the light of day in the first place, though.

Are some of the editors really so dependent on PR wires that it becomes prohibitively difficult for them to verify stories on their own - or even ping a trusted researcher over IM, for that matter? I always wondered; now, I sadly think I have the answer.

On designing UIs for non-robots

2010-08-16T19:21:00.001-07:00

In a typical, attentive human subject, the usual latency between a visual stimulus and a voluntary motor response is between 100 and 300 milliseconds. As should be evident, we do not pause for that long to assess the situation after each and every muscle movement; instead, we routinely schedule series of motor actions well in advance - and process sensory feedback only after the fact, in an asynchronous manner. Within that sub-second window of opportunity, we are simply unable to abort a premeditated action - even if things go wrong.

And here lies an interesting problem: on today's blazing fast personal computers, a lot can happen in as little as one-tenth of that timeframe. Within a browser, windows can be opened, moved around, and then closed; system prompts triggered or destroyed; programs launched and terminated. In such an environment, designing security UIs that take human cognitive limitations into account is a tricky game: any security-relevant prompt that does not enforce a certain amount of uninterrupted, distraction-free, in-focus screen time before accepting user input, is likely completely broken.

Intuitively, this just feels wrong - surely, humans can't be that bad, so the issue can't be that serious - but this is exactly the sort of a fallacy we should be trying to avoid. There is nothing, absolutely nothing, that would make attacks impractical; increasingly faster JavaScript has the ability to programatically open, position, resize, focus, blur, and close windows, and measure mouse pointer velocity and click timings with extreme accuracy; with a bit of basic ingenuity, any opportunity for a voluntary user reaction can be taken out of the equation. That's it: we suck, and there is nothing you can do to change it.

To back this claim, let's have a look at the recently-introduced HTML5 geolocation API; the initial call to navigator.geolocation.getCurrentPosition() spawns a security prompt in Firefox, Opera, Chrome, Safari, and a couple of other browsers. This UI does not implement a meaningful delay before accepting user input - and so, this crude and harmless Firefox proof-of-concept can be used to predict the timing of mouse clicks, and steal your location data with an annoyingly high success rate. This particular vector is tracked as Mozilla bug 583175, but similar problems are endemic to most of the new security UIs in place; the reason is not always simple oversight, but often, just explicit opposition to the idea of introducing usability roadblocks: after all, to a perfect human being, they are just a nuisance.

Fine-grained click timing is, of course, not where the story ends; it has been demonstrated time and time again that with minimal and seemingly innocuous conditioning, healthy and focused test subjects can be reliably duped into completely ignoring very prominent and unusual visual signals; the significance of this problem is unappreciated mostly because not many exploit writers are behavioral scientists - but that's not very reassuring thought.

There is some admirable work going on to make browser security messaging more accessible to non-technical users; but I'd wager that our problems run deeper than that. We are notoriously prone to overestimating the clarity of our perception, the rationality of our thought, and the accuracy of our actions; this is often a desirable trait when going through your life - but it tends to bite us hard when trying to design security-critical software to be used by other human beings.

We need to fight the habit the best we can, and start working on unified, secure human-to-machine interfacing in the browser. If we dismiss our inherent traits as an out-of-scope problem in security engineering, we will lose.

PS. On a somewhat related note, you may also enjoy Jesse Ruderman's recent 10-minute presentation about UI truncation attacks.

Cookies v. The People

2010-08-04T13:16:00.000-07:00

For some reason, The Wall Street Journal launched a new, large-scale offensive on web cookies - and decided to focus on the purported malice of Microsoft in particular:

"All the latest Web browsers, including Internet Explorer, let consumers turn on a feature that prevents third-party browser cookies from being installed on their computers. But those settings aren't always easy to find. Only one major browser, Apple's Safari, is preset to block all third-party cookies, in the interest of user privacy.

The Internet Explorer planners proposed a feature that would block any third-party content that turned up on more than 10 visited websites, figuring that anything so pervasive was likely to be a tracking tool.

When he heard of the ideas, Mr. McAndrews, the executive involved with Microsoft's Internet advertising business, was angry, according to several people familiar with the matter. Mr. McAndrews feared the Explorer group's privacy plans would dramatically reduce the effectiveness of online advertising by curbing the data that could be collected about consumers."

I do not have any insight into the decision process behind browser features at Microsoft - and it would be unfortunate if this factor alone had such a significant bearing on the final outcome. I do know, however, that the characterization of third-party cookie blocking as an important privacy feature is grossly misguided at best - and that there are compelling technical arguments to be made in favor of not enabling it by default.

The fundamental problem is that for better or worse, browsers necessarily make it trivial to track users across cooperating websites, without any need for the actors to appear malicious or evil. Quite simply, every computer system is unique, and browsers, by design, offer a substantial insight into it: very few other people share exactly the same browser and OS version, uptime, browser window size, installed fonts and applications as you - and so, reliable browser instance fingerprinting is certainly not science fiction.

This obvious possibility aside, there are many types of core web features that offer functionality essentially identical to cookies, and are depended on by much of the Internet; for example, RFC2616 caching allows long-lived tokens to be stored and retrieved through HTTP headers such as ETag, or simply embedded in persistently cached JavaScript code. The only reason why cookies are preferred is that they are well-known, purpose-built, have well-understood security properties, and can be managed by users easily. I encourage you to check out Ed Felten's excellent essay for more: the alternatives are very easy to embrace, but will suck for consumers more.

It is possible to build a reasonably anonymous browser, but only by crippling many of the essential features that make the modern web tick; products addressed to the general public should probably not go there. Disabling third-party cookies alone feels like a knee-jerk reaction that really does nothing to improve your privacy - and actually impacts your security. A striking example is that a ban on third-party cookies makes it very difficult to create XSRF-resilient single sign-on systems for complex, SOP-compartmentalized web applications (at least unless you introduce a dependency on JavaScript - the other Great Satan of the Internet).

To add insult to injury, because of compatibility issues, the existing third-party cookie blocking mechanisms gradually morphed into honor systems anyway: one implementation allows cookies to be set once the third-party frame is interacted with (which can be facilitated without user knowledge by having a transparent, invisble frame follow the mouse pointer for a while). Another allows cookies to be read and modified after the initial visit to a particular "third-party" site. A yet another implementation allows servers to declare good intentions by specifying a special HTTP header (P3P) to simply bypass the mechanism.

Given the way the web works, the most realistic way to improve user privacy is to create a community standard for notifying well-behaved players about your privacy preferences, and allowing them to comply. It will actually work better than the inevitable technological whack-a-mole with cookie-equivalent mechanisms: malicious parties will have the ability to track you for the foreseeable future anyway - but with explicit preference declarations, parties who want to be seen as reputable would not be able to assume that cookies are blocked simply because this is how your browser ships - and promptly switch to an alternative tracking mechanism in good faith. Commercial search engines obey robots.txt, so this system has a chance of working, too. If you disagree and distrust corporations, legislative approaches to privacy protection may be your only remaining bet.

Speaking of advisory privacy mechanisms, Microsoft actually deserves some credit rather than blame - namely, for supporting the aforementioned P3P signaling in their products: the associated HTTP headers are used to make cookie policy decisions in Internet Explorer, and not in any other browser. Alas, the protocol is a bit of a cautionary tale by itself: W3C attempted to create a complex, all-encompassing, legally binding framework to compel businesses to make honest, site-wide declarations; and the concept eventually collapsed under its own weight. Large businesses are extremely hesitant to use P3P, out of the risk of increasing their legal footprint; while small-scale web developers are simply intimidated by the monumental 110 page specification, and copy off recipes from random places on the web, with little or no regard for their intended meaning.

So yeah, privacy is hard. Blaming a browser vendor is easy. It's just not very productive.

Weekend distractions: Shannon's Ultimate Machine

2010-07-26T00:22:00.000-07:00

To continue the revered tradition of inconsequential, off-topic posts about hobby work, here's my current project:

In a desperate attempt to keep you from unsubscribing: some interesting security bugs coming soon.

"Testing takes time"

2010-07-21T11:50:00.000-07:00

When explaining why it is not possible to meet a particular vulnerability response deadline, most software vendors inevitably fall back to a very simple and compelling argument: testing takes time.

For what it's worth, I have dealt with a fair number of vulnerabilities on both sides of the fence - and I tend to be skeptical of such claims: while exceptions do happen, many of the disappointing response times appeared to stem from trouble allocating resources to identify and fix the problem, and had very little to do with testing the final patch. My personal experiences are necessarily limited, however - so for the sake of this argument, let's take the claim at its face value.

To get to the root of the problem, it is important to understand that software quality assurance is an imperfect tool. Faulty code is not written to intentionally cripple the product; it's a completely unintended and unanticipated consequence of one's work. The same human failings that prevent developers from immediately noticing all the potential side effects of their code, also put limits of what's possible in QA: there is no way to reliably predict what will go wrong with modern, incredibly complex software. You have to guess in the dark.

Because of this, most corporations simply learn to err on the side of caution: settle on a maximum realistically acceptable delay between code freeze and a release (one that still keeps you competitive!) - and then structure the QA work to be compatible with this plan. There is nothing special about this equilibrium: given resources, there is always much more to be tested; and conversely, many of the current steps could probably be abandoned without affecting the quality of the product. It's just that going in that first direction is not commercially viable - and going in the other just intuitively feels wrong.

Once a particular organization has such an QA process in place, it is tempting to treat critical security problems similar to feature enhancements: there is a clear downside to angering customers with a broken fix; on the other hand, and as long as vulnerability researchers can be persuaded to engage in long-term bug secrecy, there is seemingly no benefit in trying to get this class of patches out the door more quickly than the rest.

This argument overlooks a crucial point, however: vulnerabilities are obviously not created by the researchers who spot them; they are already in the code, and tend to be rediscovered by unrelated parties, often at roughly the same time. Hard numbers are impossible to arrive at, but based on my experience, I expect a sizable fraction of current privately reported vulnerabilities (some of them known to vendors for more than a year!) to available independently to multiple actors - and the longer these bugs allowed to persist, the more pronounced this problem is bound to become.

If this is true, then secret vulnerabilities pose a definite and extremely significant threat to the IT ecosystem. In many cases, this risk is far greater than the speculative (and never fully eliminated) risk of occasional patch-induced breakage; particularly when one happens to be a high-profile target.

Vendors often frame the dilemma the following way:

"Let's say there might be an unspecified vulnerability in one of our products.

Would you rather allow us to release a reliable fix for this flaw at some point in the future; or rush out something potentially broken?"

Very few large customers will vote in favor of dealing with a disruptive patch - IT departments hate uncertainty and fire drills; but I am willing to argue that a more honest way to frame the problem would be:

"A vulnerability in our code allows your machine to be compromised by others; there is no widespread exploitation, but targeted attacks are a tangible risk to some of you. Since the details are secret, your ability to detect or work around the flaw is practically zero.

Do you prefer to live with this vulnerability for half a year, or would you rather install a patch that stands an (individually low) chance of breaking something you depend on? In the latter case, the burden of testing rests with you.

Or, if you are uncomfortable with the choice, would you be inclined to pay a bit more for our products, so that we can double our QA headcount instead?"

The answer to that second set of questions is much less obvious - and more relevant to the problem at hand; depriving the majority of your customers of this choice, and then effectively working to conceal this fact, just does not feel right.

Yes, quality assurance is hard. It can also be expensive to better parallelize or improve automation in day-to-day QA work; and it is certainly disruptive to revise the way one releases and supports products (heck, some vendors still prefer to target security fixes for the next major version of their application, simply because that's what their customers are used to). It is also likely that if you make any such profound changes, something will eventually go wrong. None of these facts makes the problem go away, though.

Indefinite bug secrecy hurts us all by removing all real incentives for improvement, and giving very little real security in return.

Rebooting responsible disclosure!

2010-07-20T13:08:00.000-07:00

I am very proud to see this official blog post out:

"Rebooting Responsible Disclosure: a focus on protecting end users"

I am proud of this post not because it adds a yet another voice in the ongoing debate; I am proud because I think it is important and significant for a major commercial vendor to suck it up - and take a genuine, passionate stand behalf of all users instead.

The rhetoric invoked by most software vendors today is very one-sided, and aims to portray the disclosure debate as a petty feud with selfish, arrogant researchers oblivious to the realities of doing business. I find this disingenuous - and so, I sincerely hope that this blog post sets a brand new stone rolling.

PS. On a related note: it's now $3,133.7!

Guerrilla CNC home manufacturing guide

2010-07-07T02:16:00.000-07:00

There are about three people in the world who could possibly ever care about this epic work - so today, I am happy to unveil my least useful project to date: the 70,000 word CNC machining and resin casting guide for hobbyist robot builders:

You can also check out my current project.

Thank you. We now resume our regularly scheduled programming.

Hi! I'm a security researcher, and here's your invoice.

2010-07-06T13:19:00.000-07:00

It always struck me as a simple deal: there are benefits to openly participating in the security research community - peer recognition and job opportunities. There is also a cost of doing it as a hobby - loss of potential income in other pursuits. After having made a name for themselves, some people decide that the benefits no longer offset the costs - and stop spending their time on non-commercial projects. Easy, right?

Well, this is not what's on the minds of several of my respected peers. Somewhere in 2009, Alex Sotirov, Charlie Miller, and Dino Dai Zovi announced that there will be no more free bugs; in Charlie's own words:

"As long as folks continue to give bugs to companies for free, the companies will never appreciate (or reward) the effort. So I encourage you all to stop the insanity and stop giving away your hard work."

The three researchers did not feel adequately compensated for their (unsolicited) research, and opted not to disclose this information to vendors or the public - but continued the work in private, and sometimes boasted about the inherently unverifiable, secret finds.

Is this a good strategy? I think it is important to realize that many vendors, being driven by commercial incentives, spend exactly as much on security engineering as they think is appropriate - and this is influenced chiefly by external factors: PR issues, contractual obligations, regulatory risks. Full disclosure puts many of the poor performers under intense public scrutiny, and may force them to try harder and hire security talent (that's you!).

Exactly because of this unwanted pressure, they do not inherently benefit from the unsolicited services, and will probably not work with you to nourish them: if you "threaten" them by promising to essentially stop being a PR problem (unless compensated) - well, don't be surprised if they do not call back soon with a counter-offer.

Having said that, there is an interesting way one could make this work: the "pay us or else..." approach - where the "else" part may be implied to mean:

Selling the information to unnamed third parties, to use it as they see fit (with potential consequences to the vendor's customers),
Shaming the vendor in public to suggest negligence ("company X obviously values customer safety well below our $10,000 asking price"),
Simply tellling the world without giving the vendor a chance to respond if your demands are not met.

There's only one problem: I think these tricks are extremely sleazy. There are good and rather uncontroversial reasons why disclosing true information about an individual is often legal, but engaging in blackmail never is; the parallels here are really easy to draw.

This is why I am disappointed by the news of VUPEN apparently adopting a similar strategy (full article); and equally disappointed by how few people called it out:

"French security services provider VUPEN claims to have discovered two critical security vulnerabilities in the recently released Office 2010 – but has passed information on the vulnerabilities and advice on mitigation to its own customers only. For now, the company does not intend to fill Microsoft in on the details, as they consider the quid pro quo – a mention in the credits in the security bulletin – inadequate.

'Why should security services providers give away for free information aimed at making paid-for software more secure?' asked [VUPEN CEO] Bekrar."

Here's the thing: security researchers don't have to give any information away for free; but if you need to resort to arm-twisting tactics to sell a service, you have some serious soul searching to do.

Intrusion detection: doing it wrong

2010-06-22T17:57:00.000-07:00

Quite a few thick volumes have been written on the topic of securing corporate environments - but most of them boil down to the following advice:

Reduce your attack surface by eliminating non-essential services and sensibly restricting access to data,
Compartmentalize important services to lower the impact of a compromise,
Keep track of all assets and remediate known vulnerabilities in a timely manner,
Teach people to write secure code and behave responsibly,
Audit these processes regularly to make sure they actually work.

We have an array of practical methodologies and robust tools to achieve these goals - but we also have a pretty good understanding of where this model falls apart. As epitomized by Charlie Miller's goofy catchphrase, "I was not in your threat model", the reason for this is two-fold:

You will likely get owned, by kids: reasonably clued people with some time on their hands are (and for the foreseeable future will be) able to put together a fuzzer and find horrible security flaws in most of the common server or desktop software in a matter of days. Modern, large-scale enterprises with vast IT infrastructure, complex usability needs, and a diverse internal user base, are always extremely vulnerable to this class of attackers.
As a feel-good measure, this discussion is often framed in terms of high-profile vulnerability trade, international crime syndicates, or government-sponsored cyberwarfare - but chances are, the harbinger of doom will be a bored teenager, or a geek with an outlandish agenda; they are less predictable than foreign governments, too - so in some ways, we should be fearing them more.
Compartmentalization will not save you: determined attackers will take their time, and will get creative if needs be. Compartmentalization may buy a couple of days, but simply can't be designed to keep them away forever, yet keep the business thriving: as witnessed by a number of well-publicized security incidents, design compromises and poor user judgment inevitably create escalation paths.

Past a certain point, proactive measures begin to offer diminishing returns: throwing money at the problem will probably never get you to a point where a compromise is unlikely, and the business can go on. This is not a cheering prospect - but something we have to live with.

The key to surviving a compromise may lie in the capability to detect a successful attack very early on. The attackers you should be fearing the most are just humans, and have to learn about the intricacies of your networks, and the value of every asset, as they go. These precious hours may give you the opportunity to recover - right before an incident becomes a disaster.

This brings us to the topic of intrusion detection - a surprisingly hard and hairy challenge in the world of information security. Most of the detection techniques at our disposal today are inherently bypassable; this is particularly true for bulk of the tricks employed by most of the commercial AV, IDS, IPS, and WAF systems I know of. And that's where the problem lies: because the internals of these tools are essentially public knowledge, off-the-shelf intrusion detection systems often amount to a fairly expensive (and often by itself vulnerable!) tool to deter only the dumbest of attackers. A competent adversary, prepared in advance or simply catching the scent of a specific IDS toolkit, is reasonably likely to work around it without breaking a sweat.

The interesting - and highly contentious - question is what happens when the design of your in-house intrusion detection system becomes a secret. Many of my peers would argue this is actually harmful: in most contexts, security-by-obscurity does nothing to correct the underlying problems, and merely sweeps them under the rug. Yet, I am inclined to argue that in this particular case, it offers a qualitative difference. Here's why:

Let's begin by proposing a single, trivial anomaly detection rule, custom-tailored for our operating environment (and therefore, reasonably sensitive and unlikely to generate false positives); for example, it could be a simple daemon to take notice of execve() calls with stdin pointing directly to a network socket - a common sign of server-targeted shellcode. When the architecture is not shared with common commercial tools, external attackers stand a certain chance of tripping this check, and a certain chance of evading it - but this is governed almost solely by having dumb luck, and not by their skill. The odds are not particularly reassuring, but are a starting point.

(Now, an insider stands a better chance of defeating the mechanism - an unavoidable if less common problem - but a rogue IT employee is an issue that, for all intents and purposes, defies all attempts to solve it with technology alone.)

Let's continue further down this road: perhaps also introduce a simple tool to identify unexpected interactive sessions within encrypted and non-encrypted network traffic; or even a tweaked version of /bin/sh that alerts us to unusual -c or stdin payloads. Building on top of this, we can proceed to business logic: say, checks for database queries for unusual patterns, or coming from workstations belonging to users not usually engaged in customer support. Each of these checks is trivial, and stands only an average chance of detecting a clued attacker. Yet, as the chain of tools grows longer, and the number of variables that needs to be guessed perfectly right increases, the likelihood of evading detection - especially early in the process - becomes extremely low. Simplifying a bit, the odds of strolling past ten completely independent, 50% reliable checks, are just 1 in 1024; it does not matter whether the attacker is the best hacker in the world or not (unless also a clairvoyant).

For better or worse, intrusion detection seems to be an essential survival skill - and I think we are all too often doing it wrong. A successful approach on the uniqueness and diversity - and not necessarily the complexity - of the tools used; the moment you neatly package them and share the product with the world, your IDS becomes a $250,000 novelty toy.

Sadly, large organizations often lack the expertise, or just the courage, to get creative. There is a stigma of low expectations attached to intrusion detection in general, to security-by-obscurity as a defense strategy, and to maintaining in-house code that can't generate pie charts on a quarterly basis.

But when you are a high-profile target, defending only against the dumb attackers in a world full of brilliant ones - some of them driven by peculiar and unpredictable incentives - strikes me as a poor approach in the long run.

Yeah, about that address bar thing...

2010-06-22T11:46:00.000-07:00

As promised, here's another interesting browser bug, showing the perils of being user-friendly.

You are probably familiar with the usual behavior of the address bar: when you click on a link, the browser keeps showing the old location up until the new content is retrieved and actually replaces the previous page. Only Safari behaves differently, always showing the new destination - which I think can be deceptive:

<input type=submit value="Click me!" onclick="clicked()">
<script>
function clicked() {
  w = window.open("", "_blank");
  w.document.body.innerHTML = "Where do I come from?";
  w.location = 'http://1.2.3.4/';
}
</script>

I don't like this behavior, but it perhaps does not constitute an outright security flaw: the spinning throbber is a weak, but visible indicator of foul play.

But to the point! If you look carefully at the remaining browsers, you may also notice a curious exception to the rule: when a link is opened in a new window or a tab, most browsers will put the destination URL in the address bar right away. Why? Apparently, usability is the reason: doing this seemed more user-friendly than showing about:blank for a couple of seconds.

Alas, this design decision creates an interesting vulnerability in Firefox: the about:blank document actually displayed in that window while the page is loading is considered to be same origin with the opener; the attacker can inject any content there - and still keep his made up URL in the address bar.

Well, the spinning throbber is there, right? As it turns out, you can make it go away. The harder way is to use an URL that legitimately returns HTTP 204; the easier way is to simply call window.stop():

<input type=submit value="Click me!" onclick="clicked()">
<script>
var w;
function clicked() {
  w = window.open("http://1.2.3.4/", "_blank", "toolbar=1,menubar=1");
  setTimeout('w.document.body.innerHTML = "Fake content!";w.stop();', 500);
}
</script>

Reported early April, CVE-2010-1206; Mozilla addressed the glitch in release 3.6.7.

HTTPS is not a very good privacy tool

2010-06-18T11:09:00.000-07:00

Today, EFF announced HTTPS Everywhere - a browser plugin that automatically "upgrades" all requests to a set of predefined websites, such as Wikipedia, to HTTPS. This is done in a manner similar to Strict Transport Security.

Widespread adoption of encryption should be praised - but the privacy benefits of tools like this are often misunderstood. The protocol is engineered to maintain the confidentiality and integrity of a priori private data exchanged over the wire - and does very little to keep your actions private when accessing public content.

Even with HTTPS, every passive, unsophisticated attacker should be able to exactly tell which Wikipedia page you happen to be interested in: looking at packet sizes, direction, and timing patterns for encrypted HTTP requests, he can identify the resource with a high degree of confidence. With that particular site, you do not even need to crawl the content on your own: database dumps are provided by the foundation, and take a couple of hours to download over DSL.

Adding some random padding and jitter to the communications will help, but can be only taken so far without introducing a very significant performance penalty. Because of this, large-scale behavioral analysis is still likely to be very effective even if we do some of that.

Naturally, there are situations where HTTPS actually helps with privacy; but fewer than we probably come to expect. Even the contents of encrypted text typed in by the user can be reconstructed in some fascinating cases, as explored in this research paper from Microsoft.

Not the disclosure debate again?...

2010-06-17T21:56:00.001-07:00

Vulnerability researchers:

Stated incentive: make the world a safer place.

Key incentives:

Share cool stuff: good researchers are passionate about their area of expertise, and usually are in it mainly for the thrills. Like all hobbyists, they are proud of their work, want to share their achievements with others, and be praised for a job well done. The security community is unusually tightly knit, compared to IT in general, and is reminiscent of the open source movement.
Get paid: security researchers aim to make a living out of their hobby - be it by establishing and maintaining credentials in the community to land interesting gigs, or by directly trading vulnerability data.

Outcome of full disclosure policies:

Relatively frequent disruptive exploitation of unpatched vulnerabilities.
Greatly reduced window of exposure to security attacks.
Good accountability for security engineering and response practices.
Increased risk of regulatory response, establishing vendor liability standards for security flaws.

Software vendors:

Stated incentive: make the world a safer place.

Key incentives:

Protect the integrity of operations: security does not directly contribute to revenue, so it is usually impractical to disrupt business processes (including release engineering and testing workflows), or alter product lines and support approaches, to allow for rapid security response.
Don't look bad: because #1 almost always results in security response capabilities below what would be expected by customers in distress, companies strive to minimize the visibility of these shortcomings, and discourage non-compliant research practices. Failure to do so may result in loss of customer confidence - and eventually, prompt the government to step in.

Outcome of regulated disclosure policies:

Fewer large-scale attacks using unpatched vulnerabilities.
Nearly permanent, large scale susceptibility to non-public flaws for all users.
Limited accountability for security engineering and response practices.
Reduced likelihood of regulatory action.

Nobody in this debate is particularly forthcoming (Spengler included, as much as I enjoyed his post), and no solution is perfect. Only one of these groups has PR departments, though.

Browser-side XSS detectors of doom

2010-06-11T21:35:00.000-07:00

The prevalence of cross-site scripting - an unfortunate consequence of how the web currently operates - is one of the great unsolved challenges in the world of information security. Short of redesigning HTML from scratch, browser developers are not particularly well-positioned to fix this issue; but understandably, they are eager to at least mitigate the risk.

One of the most publicized efforts along these lines is the concept of browser-side, reflected XSS detectors: the two most notable implementations are David Ross' XSS filter (shipping in Internet Explorer 8) and Adam Barth's XSS Auditor (WebKit browsers - currently in Safari 5). The idea behind these tools is very simple: if query parameters seen in the request look suspiciously close to any "active" portions of the rendered page, the browser should assume foul play - and step in to protect the user.

Naturally, nothing is that simple in the browser world. The major design obstacle is that the check has to be passive - active probes are likely to cause persistent side effects on the server. Because of this, the detector can merely look for correlation, but not confirm causation; try this or this search in Internet Explorer 8 to see a canonical example of why this distinction matters.

Since passive checks inevitably cause false positives, the authors of these implementations defaulted to a non-disruptive "soft fail" mode: when a suspicious pattern is detected, the browser will still attempt to render the page - just with the naughty bits selectively removed or defanged in some way.

While a fair amount of issues with XSS detectors were pointed in the past - from hairy implementation flaws to trivial bypass scenarios - the "soft fail" design creates some more deeply rooted problems that may affect the safety of the web in the long run. Perhaps the most striking example is this snippet, taken from a real-world website:

<script>
...
// Safari puts <style> tags into new <head> elements, so
// let's account for this here.
...
</script>
...
[ sanitized attacker-controlled data goes here ]

The data displayed there is properly escaped; under normal circumstances, this page is perfectly safe. But now, consider what happens if the attacker-controlled string is } body { color: expression(alert(1)) } - and ?q=<script> is appended by at the end of the URL. The filter employed in MSIE8 will neutralize the initial <script>, resulting in the subsequent <style> tag being interpreted literally - putting the browser in a special parsing mode. This, in turn, causes the somewhat perverted CSS parser to skip any leading and trailing text, and interpret the attacker-controlled string as a JavaScript expression buried in a stylesheet.

Eep. This particular case should be fixed by the June security update, but the principle seems dicey.

The risk of snafus like this aside, the fundamental problem with XSS detectors is that quite simply, client-side JavaScript is increasingly depended upon to implement security-critical features. The merits of doing so may be contested by purists, but it's where the web is headed. No real alternatives exist, too: a growing number of applications uses servers merely as a dumb, ACL-enforcing storage backend, with everything else implemented on client side; mechanisms such as localStorage and widget manifests actually remove the server component altogether.

To this client-heavy architecture, XSS detectors pose an inherent threat: they make it possible for third-party attackers to selectively tamper with the execution of the client-side code, and cause the application to end up in an unexpected, inconsistent state. Disabling clickjacking defenses is the most prosaic example; but more profound attacks against critical initialization or control routines are certainly possible, and I believe they will happen in the future.

The skeptic in me is not entirely convinced that XSS filters will ever be robust and reliable enough to offset the risks they create - but I might be wrong; time will tell. Until this is settled, I and several other people pleaded for an opt-in strict filtering mode that prevents the page from being rendered at all when a suspicious pattern is detected. Now that it is available, enabling it on your site is probably a good idea.

The curse of inverse strokejacking

2010-06-08T14:00:00.000-07:00

This is the third interesting bug I had in my pipeline for a while. It's far less scary than the previous ones, but nevertheless, probably amusing enough.

A while ago, I posted a whimsical proof of concept for what I greatly enjoy calling strokejacking. The problem amounts to this: a rogue site can put an unrelated, third-party web application in a hidden frame - and then, by offering some seemingly legitimate functionality, entice the user to type in a body of text. As the user is typing, the attacker is free to examine key codes from within the onkeydown handler - and when desired, momentarily move focus to said hidden frame, causing the actual onkeypress event to be routed there instead. The trick essentially permits arbitrary, attacker-controlled input to be synthesized on the targeted site - possibly changing victim's privacy settings, setting up mail forwarding, or authorizing new users to access personal data.

The attack is arguably more interesting than your traditional, run-of-the-mill clickjacking, mostly because it allows for more complex interactions. Still, in most cases, it can be prevented the same way - with X-Frame-Options or with framebusting JavaScript - so no reason to panic, right?

Well, there's a twist: shortly after reporting this problem publicly several months ago, I realized that the attack scenario could be reversed. Consider a third-party gadget or an advertisement framed on a legitimate page, a pretty common pattern today. The frame is free to grab focus from the top-level document, as this operation is not governed by the same-origin policy. Normally, this causes the caret to disappear from where the user is expecting it to be - but by briefly giving up focus at strategically timed intervals, the appearance of a blinking cursor in the top-level document can be maintained. The rogue gadget can then read all the typed characters via onkeydown - and have onkeypress delivered to the top-level document, so that everything seems to be working as expected - with an extra copy of all the data silently delivered to the attacker.

A simple WebKit-specific proof of concept can be found here. The usual clickjacking defenses are not applicable in this scenario, for obvious reasons.

WebKit bug: 26824. Firefox bug: 552255. CVE-2010-1422.

Announcing ref_fuzz, a 2 year old fuzzer

2010-06-08T10:30:00.000-07:00

Somewhere in 2008, I created a relatively simple DOM binding fuzzer dubbed ref_fuzz. The tool attempted to crawl the DOM object hierarchy from a particular starting point, collect object references discovered during the crawl by recursively calling methods and examining properties, and then reuse them in various ways after destroying the original object. In essence, the goal was to find use-after-free conditions across the browser codebase.

The fuzzer managed to crash all the mainstream browsers on the market at that time, in a number of seemingly exploitable ways. Early fixes from Opera and Apple started shipping somewhere in 2008; some more arrived in 2009. Today, Microsoft released a fix and a bulletin for CVE-2010-1259 (MS10-035), while Apple released fixes for CVE-2010-1119 - fixing the last of the scary memory corruption cases attributed to the tool.

The story of ref_fuzz is interesting, because to some extent, it illustrates the shortcomings of one-way responsible disclosure. Were I to release this fuzzer publicly in 2008, it would probably cause some short-term distress - but in the end, vendor response would likely be swift, out of simple necessity; this certainly proved to be the case with mangleme, a comparably effective fuzzer I developed 2004 (my rebel years).

In this particular case, however, the appropriate parties were notified privately, with no specific disclosure deadline given. This, coupled with the inability to create simple repro cases (inherently due to the design of the fuzzer), likely prompted the developers to deprioritize investigating and responding to these flaws - in the end, taking months or years instead of days or weeks. Given that they need to respond to hundreds or thousands of seemingly more urgent bugs every year, this is not unexpected.

What's more troubling is that, within that timeframe, many of the crashes triggered by ref_fuzz were independently rediscovered and fixed: several exploitable crashes were patched without attribution by Microsoft in December 2009 (MSRC cases 9480jr and 9501jr); similarly, several WebKit flaws were rediscovered by Alexey Proskuryakov and addressed in WebKit earlier this year (say, bug 33729), and by Pwn2Own winners shortly thereafter. Is it unreasonable to assume that malicious researchers were just as likely to spot these glitches on their own?

In any case - I am happy to finally release the tool today. You can check out the fuzzer here (warning: clicking on this link may cause your browser to misbehave).

Safari: a tale of betrayal and revenge

2010-06-07T19:00:00.000-07:00

Looks like I am finally free to discuss the first interesting browser bug on my list - so here we go. I really like this one: its history goes back to 1994, and spans several very different codebases. The following account is speculative, but probably a pretty good approximation of what went wrong.

Let's begin with this simple URL:

http:example.com/

This syntax demonstrates an unintentional and completely impractical quirk in the URL parsing algorithm specified some 16 years ago in RFC 1630. Verbatim implementations are bound to parse this string as a relative reference to protocol = 'http', host = $base_url.host, path = 'example.com/'. It does not make a whole lot of sense, and indeed, in RFC 3986, Tim Berners-Lee had this to say:

"This is considered to be a loophole in prior specifications of partial URI [RFC1630]. Its use should be avoided but is allowed for backward compatibility."

Fast forward two years: the KDE team is working on a new open-source browser, Konqueror. Their browser uses KURL as the canonical URL parsing library across the codebase. This parser behaves in an RFC-compliant way when handling our weird input string, with one seemingly unimportant difference: if the current parsing context does not have a valid host name associated with it, the address is not rejected as unresolvable; the host name is simply set to an empty string. No big deal, right?

Well, somewhere around 2002, the renderer and the JavaScript engine used in Konqueror - KHTML and KJS - are forked off under the name of WebKit, and become the foundation for Safari. The fork contains almost all the necessary core components for a browser, with a notable exception of a built-in HTTP stack - and so, Apple decides to reuse their existing CFNetwork library for this purpose. When our special URL finally makes it to this library, it is interpreted in a far more intuitive, but technically less correct way - as protocol = 'http', host = 'example.com', path = '/'; HTTP cookies and other request parameters are then supplied accordingly.

The result? When you open two windows in Safari - one pointing to http:hairy-spiders.com, and the other pointing to http:fuzzy-bunnies.com - the HTTP stack will make sure they are populated with cookie-authenticated data coming from the two different servers named in the URLs; but the same origin checks within the browser will rely on KURL instead. Remember how KURL spews out an empty host name in both cases? Because empty strings always match, both pages are deemed to be coming from the same source, and can access each other at will. Oops.

Well, there's still a catch: this attack will only work as expected if the windows are opened by hand; in documents opened from a web page, the host name from the base URL will interfere with how the URLs are broken down. Thankfully, we can work around it, simply by hopping through a data: URL.

Reported to the vendor in January 2010, fixed in Safari 4.1 and 5.0 (APPLE-SA-2010-06-07-1, CVE-2010-0544). A simple and harmless proof-of-concept can be found here.

Several responses to "broken promises"

2010-06-03T12:09:00.000-07:00

I am very surprised by the number of reactions to the previous entry in this blog. Here are some particularly interesting, full-length responses from my acclaimed peers:

Ivan Arce (Core Security),
David LeBlanc (Microsoft),
Amrit Williams (BigFix),
Charles Smutz (Lockheed Martin).

I complained about the failings of formal methods, and failed to acknowledge that at times, more pragmatic approaches to security testing work just fine. That's true - but allow me to clarify: the excerpt comes from an introduction to an upcoming book, and simply explains why the remainder of this work will not focus on any sort of an overarching security engineering paradigm. The book indeed advocates simple, technical-minded pragmatism instead.

Alas, down-to-earth pragmatism seldom moves products off the shelves. As a result, our industry is extremely prone to harmful hyperboles - and so, it deserves a mild slap on the wrist. This alone makes me think the original post stands on its own merit.

PS. Then, there's a response from David Mortman, complaining about people who complain.

Security engineering: broken promises

2010-05-17T11:17:00.001-07:00

The following draft excerpt comes from my upcoming book. Republished with permission of No Starch Press.

On the face of it, the field of information security appears to be a mature, well-defined, and an accomplished branch of computer science. Resident experts eagerly assert the importance of their area of expertise by pointing to large sets of neatly cataloged security flaws, invariably attributed to security-illiterate developers; while their fellow theoreticians note how all these problems would have been prevented by adhering to this year's hottest security methodology. A commercial industry thrives in the vicinity, offering various non-binding security assurances to everyone, from casual computer users to giant international corporations.

Yet, for several decades, we have in essence completely failed to come up with even the most rudimentary, usable frameworks for understanding and assessing the security of modern software; and spare for several brilliant treatises and limited-scale experiments, we do not even have any real-world success stories to share. The focus is almost exclusively on reactive, secondary security measures: vulnerability management, malware and attack detection, sandboxing, and so forth; and perhaps on selectively pointing out flaws in somebody else's code. The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, we deliver far less value than could be expected.

So, let's have a look at some of the most alluring approaches to assuring information security - and try to figure out why they fail to make a difference to regular users and businesses alike.

Flirting with formal solutions

Perhaps the most obvious and clever tool for building secure programs would be simply to algorithmically prove they behave just the right way. This is a simple premise that intuitively, should be within the realm of possibility - so why hasn't this approach netted us much?

Well, let's start with the adjective “secure” itself: what is it supposed to convey, precisely? Security seems like a simple and intuitive concept, but in the world of computing, it escapes all attempts to usefully specify it. Sure, we can restate the problem in catchy, yet largely unhelpful ways – but you know we have a problem when one of the definitions most frequently cited by practitioners is:

“A system is secure if it behaves precisely in the manner intended – and does nothing more.”

This definition (originally attributed to Ivan Arce) is neat, and vaguely outlines an abstract goal – but then tells very little on how to achieve it. It could be computer science - but in terms of specificity, it just as easily could be a passage in Victor Hugo's poem:

“Love is a portion of the soul itself, and it is of the same nature as the celestial breathing of the atmosphere of paradise.”

Now, one could argue that practitioners are not the ones to be asked for nuanced definitions - but, ask the same question to a group of academics, and they will deliver roughly the same. The following common academic definition traces back to Bell-La Padula security model, published back in the sixties (one of about a dozen attempts to formalize the requirements for secure systems - in this particular case in terms of a finite state machine – and one of the most notable ones):

“A system is secure if and only if it starts in a secure state and cannot enter an insecure state.”

Definitions along these lines are fundamentally true, of course, and may serve as a basis for dissertations, perhaps a couple of government grants; but in practice, any models built on top of them are bound to be nearly useless for generalized, real-world software engineering. There are at least three reasons for this:

There is no way to define desirable behavior of a sufficiently complex computer system: no single authority can spell out what the “intended manner” or “secure states” are supposed to be for an operating system or a web browser. The interests of users, system owners, data providers, business process owners, and software and hardware vendors, tend to differ quite significantly and shift rapidly – if all the stakeholders are capable and willing to clearly and honestly disclose them out to begin with. To add insult to injury, sociology and game theory suggest that computing a simple sum of these particular interests may not actually result in a satisfactory outcome; the dilemma, known as “the tragedy of the commons”, is central to many disputes over the future of the Internet.
Wishful thinking does not automatically map to formal constraints: even if a perfect high-level agreement of how the system should behave can be reached in a subset of cases, it is nearly impossible to formalize many expectations as a set of permissible inputs, program states, and state transitions – a prerequisite for almost every type of formal analysis. Quite simply, intuitive concepts such as “I do not want my mail to be read by others” do not translate to mathematical models particularly well - and vice versa. Several exotic approaches that let such vague requirements to be at least partly formalized exist, but they put heavy constraints on software engineering processes, and often result in rulesets and models far more complicated than the validated algorithms themselves – in turn, likely needing their own correctness to be proven... yup, recursively.
Software behavior is very hard to conclusively analyze: static analysis of computer programs to prove they would always behave in accordance to a detailed specification is a task that nobody managed to believably demonstrate in complex real-world scenarios (although as usual, limited success in highly constrained settings or with very narrow goals is possible). Many cases are likely to be impossible to solve in practice (due to computational complexity) – or even may turn out to be completely undecidable due to the halting problem.

Perhaps more frustrating than the vagueness and uselessness of these early definitions is that as decades fly by, little or no progress is made on coming up with something better; in fact, a fairly recent academic paper released in 2001 by the Naval Research Laboratory backtracks some of the earlier work, and arrives at a much more casual, enumerative definition of software security: one that explicitly disclaims it is imperfect and incomplete:

“A system is secure if it adequately protects information that it processes against unauthorized disclosure, unauthorized modification, and unauthorized withholding (also called denial of service). We say 'adequately' because no practical system can achieve these goals without qualification; security is inherently relative.”

The paper also provides a retrospective assessment of earlier efforts, and the unacceptable sacrifices made to preserve the theoretical purity of said models:

“Experience has shown that, on one hand, the axioms of the Bell-La Padula model are overly restrictive: they disallow operations that users require in practical applications. On the other hand, trusted subjects, which are the mechanism provided to overcome some of these restrictions, are not restricted enough. [...] Consequently, developers have had to develop ad hoc specifications for the desired behavior of trusted processes in each individual system.”

In the end, regardless of the number of elegant, competing models introduced, all attempts to understand and evaluate the security of real-world software using algorithmic foundations seem to be bound to fail. This leaves developers and security experts with no method to make authoritative statements about the quality of produced code. So, what are we left with?

Risk management

In absence of formal assurances and provable metrics, and given the frightening prevalence of security flaws in key software relied upon by modern societies, businesses flock to another catchy concept: risk management. The idea, applied successfully to the insurance business (as of this writing, with perhaps a bit less to show for in the financial world), simply states that system owners should learn to live with vulnerabilities that would be not cost-effective to address, and divert resources to cases where the odds are less acceptable, as indicated by the following formula:

risk = probability of an event * maximum loss

The doctrine says that if having some unimportant workstation compromised every year is not going to cost the company more than $1,000 in lost productivity, maybe they should just budget this much and move on – rather than spending $10,000 on additional security measures or contingency and monitoring plans. The money would be better allocated to isolating, securing, and monitoring that mission-critical mainframe that churns billing records for all customers instead.

Prioritization of security efforts is a prudent step, naturally. The problem is that when risk management is done strictly by the numbers, it does deceptively little to actually understand, contain, and manage real-world problems. Instead, it introduces a dangerous fallacy: that structured inadequacy is almost as good as adequacy, and that underfunded security efforts plus risk management are about as good as properly funded security work.

Guess what? No dice:

In interconnected systems, losses are not capped, and not tied to an asset: strict risk management depends on the ability to estimate typical and maximum cost associated with a compromise of a resource. Unfortunately, the only way to do it is to overlook the fact that many of the most spectacular security breaches in history started in relatively unimportant and neglected entry points, followed by complex access escalation paths, eventually resulting in near-complete compromise of critical infrastructure (regardless of any superficial compartmentalization in place). In by-the-numbers risk management, the initial entry point would realistically be assigned a lower weight as having low value compared to other nodes; and the internal escalation path to more sensitive resources would be likewise downplayed as having low probability of ever being abused.
Statistical forecasting does not tell you much about your individual risks: just because on average, people in the city are more likely to be hit by lightning than mauled by a bear, does not really mean you should bolt a lightning rod to your hat, but then bathe in honey. The likelihood of a compromise associated with a particular component is, on an individual scale, largely irrelevant: security incidents are nearly certain, but out of thousands exposed non-trivial resources, any resource could be used as an attack vector, and none of them is likely to see a volume of events that would make statistical analysis meaningful within the scope of the enterprise.
Security is simply not a sound insurance scheme: an insurance company can use statistical data to offset capped claims that might need to be paid across a large, well-studied populace, using the premiums collected from every participant; and to estimate reserves needed to deal with random events, such as sudden, localized surges in the number of claims, up to a chosen level of event probability. In such a setting, formal risk management works pretty well. In contrast, in information security, there is no meaningful way to measure how dangerous your current practices may be; no way to detect and estimate the impact of breaches when they occur in order to build a baseline; and no way to cleanly offset the costs of a breach with the value contributed by healthy assets.

Enlightenment through taxonomy

The two schools of thought discussed previously have something in common – both assume that it is possible to define security as a set of computable goals, and that the resulting unified theory of a secure system or a model of acceptable risk would then elegantly trickle down, resulting in an optimal set of low-level actions needed to achieve perfection in application design.

There is also the opposite approach preached by some practitioners – owing less to philosophy, and more to natural sciences: that much like Charles Darwin back in the day, by gathering sufficient amounts of low-level, experimental data, we would be able to observe, reconstruct, and document increasingly more sophisticated laws, until some sort of a unified model of a secure computing is organically arrived at.

This latter world view brings us projects like the Department of Homeland Security-funded Common Weakness Enumeration (CWE). In the organization's own words, the goal of CWE is to develop a unified “Vulnerability Theory”; to “improve the research, modeling, and classification of software flaws”; and “provide a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities". A typical, delightfully baroque example of the resulting taxonomy may be:

Improper Enforcement of Message or Data Structure → Failure to Sanitize Data into a Different Plane → Improper Control of Resource Identifiers → Insufficient Filtering of File and Other Resource Names for Executable Content.

Today, there are about 800 names in this dictionary; most of them as discourse-enabling as the one quoted here.

A slightly different school of naturalist thought is manifested in projects such as the Common Vulnerability Scoring System (CVSS), a business-backed collaboration aiming to strictly quantify known security problems in terms of a set of basic, machine-readable parameters. A real-world example of the resulting vulnerability descriptor may be:

AV:LN / AC:L / Au:M / C:C / I:N / A:P / E:F / RL:T / RC:UR / CDP:MH / TD:H / CR:M / IR:L / AR:M

Given this 14-dimensional vector, organizations and researchers are expected to transform it in a carefully chosen, use-specific manner – and arrive at some sort of an objective, verifiable, objective conclusion about the significance of the underlying bug (say, “42”), precluding the need to more subjectively judge the nature of security flaws.

I may be poking gentle fun at their expense - but rest assured, I do not mean to belittle these CWE or CVSS: both projects serve noble goals, most notably giving a more formal dimension to risk management strategies implemented by large organizations (any general criticisms of certain approaches to risk management aside). Having said that, none of them yielded a grand theory of secure software yet - and I doubt such a framework is within sight.

[...end of excerpt...]

Postcards from the antivirus world

2010-05-07T22:59:00.000-07:00

"Researchers say they've devised a way to bypass protections built in to dozens of the most popular desktop anti-virus products, including those offered by McAfee, Trend Micro, AVG, and BitDefender." - The Register

Sounds familiar? For the past three years or so, such headlines have appeared in the press on a fairly regular basis. This makes one wonder: is there something rotten in the antivirus world? After all, of all things, we ought to be able to get the security tools right.

Well, the picture is more complicated than it may seem. We intuitively draw parallels between these findings and the vulnerabilities commonly found in other types of software - but the issue here is very different: all consumer-grade antivirus software simply must be designed to be bypassable, even if only transiently so. To understand this, we need to realize that there is nothing fundamentally different between a botnet client and a legitimate chat application: they both use roughly the same OS facilities in a very similar manner, and while differences are often observed in practice, they are not essential in any way. The intent of the actions performed by these two programs is the only distinguishing factor. Yet, this property can't be algorithmically assessed - not only because the task is notoriously hard to formalize, but also because automated reasoning about the behavior of computer programs is, in many cases, provably impossible.

Because of this, the antivirus model is nothing like that of "proper" security tools. Instead of eliminating essential mechanisms depended on by the rogue code, AV software tries to stop specific, previously recorded attack patterns: known bad binaries, known suspicious sequences of system calls, and so forth. Some heuristics are employed, but in the end, it always comes down to blacklisting - a canonical bad practice in the field of information security. Surprisingly, in this particular context, it actually works:

Most users are not running up-to-date antivirus software - therefore, there is relatively little incentive for attackers to spend too much time on evading the checks. As a result, most of the malicious code you can run into will trip existing signatures or simple behavioral heuristics. The users of antivirus products remain at a distinct advantage.
Although a percentage of new malware is created specifically to avoid detection, the two possible outcomes are just as favorable to the users of antivirus products:
- When malware authors aim for rapid, nondiscriminate propagation, the new variant is quickly captured in the wild, and the tools are updated with new signatures or scan algorithms. In this case, a majority of users are protected before they come into contact with the new payload.
- When malware authors want to stay under the radar, and only go after select targets, the majority of users are not interesting enough to end up in the crosshairs - and therefore, the problem is highly self-limiting.

As should be evident, this model works reasonably well to protect casual users. It also tends to fall apart for any entity interesting enough to attract specific attention of determined (but not necessarily skilled!) attackers; for these targets, antivirus software perhaps reduces operational costs by reducing the likelihood of nuisance infections, but does relatively little to prevent more serious trouble.

Some of the recent reports of antivirus bypass tricks are interesting (this particular research rehashes a problem that all ptrace()-based debuggers and sandboxing tools have to deal with) - but in light of the above, I am inclined to think they do not constitute a security flaw. The attention they nevertheless receive demonstrates that we have only a vague idea of the limitations of AV applications; sadly, with poor understanding, come unrealistic expectations - a major foe of any and all security work.

PS. It is frustrating that contemporary computers are so confusing and vulnerable, that we need such a wonderfully imperfect mechanism to protect the casual user to begin with. That, however, is a wholly different tale.

Vulnerability databases and pie charts don't mix

2010-05-06T15:19:00.000-07:00

There are quite a few extensive vulnerability databases in existence today. While their value in the field of vulnerability management is clear and uncontroversial, a relatively new usage pattern can also be seen: the data is being incorporated into high-level analyses addressed predominantly to executive audiences and the media to provide insight into the state of the security industry; threat reports from IBM and Symantec are good examples of this. Which vendor is the most responsive? Who has the highest number of high-risk vulnerabilities? These and many other questions are just begging to be objectively answered with a clean-looking pie chart.

Vulnerability researchers - the people behind the data points used - are usually fairly skeptical of such efforts; but their criticisms revolve primarily around the need to factor in bug severity, or the potential for cherry-picking the data to support a particular claim. These flaws are avoidable in a well-designed study. Are we good, then?

Well, not necessarily so. The most important problem is that today, for quite a few software projects, the majority of vulnerabilities is discovered through in-house testing - and the attitudes of vendors when it comes to discussing these findings publicly tend to vary. This has a completely devastating impact on the value of the analyzed data: vulnerability counting severely penalizes forthcoming players, benefits the more secretive ones, and places the ones who do not do any proactive work somewhere in between.

Consider this example from the browser world: in recent years, the folks over at Microsoft started doing a lot of in-house fuzzing, and have undoubtedly uncovered hundreds of security flaws in Internet Explorer and elsewhere. It appears to be their preference not to routinely discuss these problems, however - often silently targeting fixes for service packs or other cummulative updates instead. In fact, here's an anecdote: I reported a bunch of exploitable crashes to them in September 2009, only to see them fixed them without attribution in December that year. The underlying flaws were apparently discovered independently during internal cleanups. So be it: as long as bugs get fixed, we all benefit, and Microsoft is definitely working hard in this area.

Contrast this approach with Mozilla, another vendor doing a lot of successful in-house security testing (in part thanks to the amazing work of Jesse Ruderman). They are pretty forthcoming about their results, and announce internal, fuzzing-related fixes almost every month. Probably to avoid shooting themselves in the foot in vulnerability count tallies, they tend to report them cummulatively as crashes with evidence of memory corruption, however - and usually assign them a single CVE number to this every month. Again, sounds good.

Lastly, have a look at Chromium; several folks are fuzzing the hell out of this browser, too - but the project opts to track these issues individually, partly because the need to coordinate with WebKit developers - and each one of them ends up with a separate CVE entry. The result? Release notes often look like this.

All these approaches have their merits - but how do you reconcile them for the purpose of vulnerability counting? And, is it fair to compare any of the above players with vendors who do not seem to be doing any proactive security work at all?

Well, perhaps the browser world is special; one could argue that at least some products with matching security practices must exist - and these cases should be directly comparable. Maybe, but the other problem is the quality of the databases themselves: recent changes to the vulnerability handling process, including the emergence of partial- or non-disclosure, the popularity of vulnerability trading, and the demise of centralized vulnerability discussion channels, all make it prohibitively difficult for database maintainers to reliably track issues through their lifetime. Common problems include:

The inability to fully understand what the problem actually is, and what severity it needs to be given. Database maintainers cannot be expected to be intimately familiar with every product, and need to process thousands of entries every year - but this often leads to vulnerability notes that may at first sight appear inaccurate, hard to verify, or very likely not worth classifying as security flaws at all.
The difficulty discovering how the disclosure process looked like, and how long the vendor needed to develop a patch. This is perhaps the most important metric to examine when trying to understand the performance of a vendor - yet one that is not captured, or captured very selectively and inconsistently, in most of the databases I am aware of.
The difficulty detecting the moment when a particular flaw is addressed - all the databases contain a considerable number of entries that were not updated to reflect patch status (apologies for Chrome-specific examples). There seems to be correlation between the prevalence of this problem and the mode in which vendor responses are made available to the general public. Furthermore, when a problem is not fixed in a timely manner, the maintainers of the database generally do not reach out to the vendor to investigate why: is the researcher's claim contested, or is the vendor simply sloppy? This very important distinction is lost.

Comparable problems apply to most other security-themed studies that draw far-fetching conclusions from simple numerical analysis of proprietary data. Pie charts don't immediately invalidate a whitepaper, but blind reliance on these figures warrants a closer investigation of the claims.

Address bar and the sea of darkness

2010-04-28T21:38:00.000-07:00

I have no idea why this is still unclear:

THE CURRENT CONTENTS OF THE ADDRESS BAR ARE YOUR ONLY GOD.

Really. There is nothing else: browsers do not have any other universal, reliable content origin indicator, and no way to predict where you will be taken next. People who do not understand this, or who do not understand the URL syntax, will suffer. Over and over again.

It is fair to note that way too many users fall into this category; in fact, even the experts can't always be sure. Guess where the following URLs will take you in MSIE, Firefox, and Chrome:

http://example.com\@coredump.cx/
http://example.com;.coredump.cx/

Chances are, you got the answers wrong. The problem is easy to pin squarely on the users, but it's the geeks who created a huge gap between the skill level needed to proficiently operate a browser, and the skill level required to do so safely. The health of the entire networked ecosystem suffers as a result.

This gap is one of the great unsolved problems in information security - and it calls for fundamental changes to how web browsers interact with the users and identify sites. Alas, not every quick kludge is necessarily a good one: careless users will be exactly just as doomed if we outlaw HTTP authentication, change onclick behavior, rework tooltips, or close all the open redirectors in the world. The few hundred remaining pages in the relevant RFCs make the world interesting. Please, pick your battles wisely.

Vulnerability trading markets and you

2010-04-28T11:46:00.000-07:00

I should soon be able to share several really interesting browser design flaws, but until then, let me kill some more time by getting on the soapbox again.

There is something interesting going on in the security industry: we are witnessing the rapid emergence of vulnerability trading markets. Hundreds of security researchers now routinely sell exploits to intermediaries for an easy profit (anywhere from $1,000 to $50,000), instead of talking to the vendors or announcing their findings publicly; these intermediaries in turn sell the knowledge to unspecified end users, most likely at several times the original price tag. Some intermediaries may eventually release the information to the public; others withhold it indefinitely. Predictably, the latter bunch is willing to pay you a lot more.

The interesting part is that both classes of intermediaries often demand weaponized, multi-platform exploits, and not just a nice write-up on the nature of the glitch. Apparently, some of their valued customers are less interested in just knowing how to detect the vulnerability or deploy robust workarounds, and want an efficient attack tool instead. Why? Some use cases in the IDS industry could be strenuously made, but I do not find them all that believable. If not this, then what's going on?

A likely hypothesis is that at the end of the chain, you can find several players who are not exactly benevolent, and have a clear business case to justify the significant expense, or the need to go through multiple hops (as opposed to hiring local talent at fraction the price). When confronted about this, the intermediaries usually allude to unspecified government agencies - but even if this somewhat uncomfortable claim is true, there is a slight problem: the researcher does not get to choose which government he may be aiding with his work.

Many people find it difficult to sympathize with Jethro's legal troubles: he was offered a lot of money, in cash, for an exploit that would rather obviously be used for something illegal or at least morally dubious - and didn't think twice. While the proxy arrangement practiced by the industry may superficially look different, I am not sure it really is: can the sellers honestly claim they understand who wants these exploits, and why do these tools happen to be so unusually valuable? And if not, should we be selling them for a lot of money, no questions asked?

There is an argument made by Charlie Miller and several other researchers that the vendors should not be entitled to free vulnerability research services from the security community. Maybe so - although it's worth noting that researchers profit from that bona fide work by gaining recognition and respect, and landing cool jobs later on; vendors gain much less from the extra public scrutiny, and some of them would probably prefer for this arrangement to go away. But in any case, I do not think this argument genuinely supports the idea of selling the information to the highest bidder with no regard of how it may be used: it may be legal, and it may be profitable, but it certainly does not feel right.

Responsibilities in vulnerability disclosure

2010-04-27T22:23:00.000-07:00

The debate around responsible disclosure is as old as the security industry itself, and unlikely to be settled any time soon. Tellingly, both sides of the debate claim to be driven by the same motive - to keep users safe. Yet, both accuse the opponent of saying so under false pretenses: vendors and businesses see full disclosure proponents as attention whores, while researchers think vendors only care only about PR and legal liability damage control.

The controversy will continue, and it would be pointless to recapture it here. Having said that, I have an issue with one of the common assumptions made in this debate: the belief that vulnerabilities are unlikely to be discovered by multiple parties at once, and therefore, the original finder of a flaw is in a unique position to control the information. Intuitively, it sounds pretty reasonable: security research is hard, and the necessary skills are nearly impossible to formalize or imitate. The press, in particular, likes to think of vulnerability finding as an arcane form of art. But is it so?

I found over 200 vulnerabilities in high-profile client- and server-side apps. I think it is a pretty good data set to work with - and curiously, I am strongly convinced that none of these findings should be attributed to my unique brilliance or skill, divine intervention, or any other unique circumstances that could not be easily reproduced elsewhere. It feels that a vast majority of these findings were just a matter of the security community reaching a certain critical body of knowledge - gaining a better understanding of what can go wrong, where to look for it, and how to automate the testing with simple fuzzers and similar validation frameworks. At that point, finding bugs is simply a matter of picking a target to go after; who happens to be behind the wheel is largely immaterial.

What's more, I found that when you go after a sufficiently buggy and complex application, most of the problems you find would turn out to be dupes of what other researchers discovered weeks or months earlier. This pattern proved to be particularly prevalent in the browser world, where I had multiple bug collisions with Georgi Guninski or Amit Klein.

I suspect the same can be said by a vast majority of other security researchers - though not all of them are willing to make the same self-deprecating admission in public. Sadly, by enjoying being portrayed as wizards, we are also making it easier for vendors to advocate the view that the discovery of a vulnerability is what creates a threat - and that researchers have an obligation to wait indefinitely to help protect users against attacks.

While giving a responsive vendor some advance notification is often a good idea, creating a social pressure on researchers to wait for patches removes any incentive for vendors to respond in a timely manner. This would not be a problem if vendors were consistently awesome - but they certainly aren't today. We are commonly seeing some of the leading proponents of responsible disclosure taking from six months to two years to address even fairly simple, high-risk bugs - and seldom facing any criticism for this. Researchers who behave "irresponsibly", on the other hand, are routinely called names if they are lucky; and are formally or informally threatened if not.

Vulnerability disclosure, however done, does not make you less secure. More often that we are willing to admit, it merely brings out an existing risk from the thriving underground market and into the spotlight. Naturally, this can be disruptive in the short run, which is why the practice is controversial; it's certainly easier not to have to scramble to fix an issue on a short notice. That said, timely and verbose disclosure also levels the playing field by keeping vendors accountable, and giving all users the information needed to limit exposure - even if by stopping to use a particular service until a fix is available.

Is this thing on?

2010-04-27T21:54:00.000-07:00

The Usenet is long dead, and mailing lists such as BUGTRAQ or full-disclosure seem to be on their way out, too. A growing number of security researchers opts to discuss their research on Twitter, through blogs, or by directly reaching out to the media.

For what it's worth, I think it's a bad idea: instead of having a single aggregation point for all the industry news, you now need to maintain a long list of researchers to follow, painstakingly discover new sources through social networking, and filter a lot of noise. But, it also seems to be the way we are doing business these days - so no point in whining.

In this spirit, and because people who do not follow the aforementioned lists usually think I am dead, I decided to check out this newfangled blogging thing. I promise to update it infrequently and to generally make very little sense. To kick it off, here are some recent developments to share:

New tools, etc: I released skipfish - a ridiculously fast site brute-forcing and security testing tool. It is really snappy and generates pretty, interactive reports with virtually no fluff. Several people on Twitter reported problems with their scans, but this page covers most of the issues you can run into. Of slightly older developments, you may enjoy the Browser Security Handbook or ratproxy.
Vulnerability research: after some painful experiences, I posted a list of upcoming vulnerabilities on my home page, and will try to keep it up to date. One of the most notable cases is ref_fuzz - series of exploitable, fuzzer-triggered DOM crashes that remain unfixed in MSIE and Safari almost two years after the inception of the tool.
Geeky hobbies: mechanically-inclined folks may be interested in my 2.5D imaging project, a cheesy Geiger-Müller mood lamp, or my guerrilla CNC guide. I also have some new photos to show.