Michal Zalewski includes an important paragraph towards the end of his analysis of the MHTML exploit affecting Google users as well as “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.

Great to see the evolution has been included in the discussion. That was one of my points in my BSidesSF presentation when I criticized Symantec and McAfee for their analysis of certain infamous incidents. It felt like it was becoming too easy for security analysts to push the ZOMG button instead of taking time to trace and explain the development path that attackers followed. Certain shortcuts taken by Microsoft in 2007, for example, could have been called out for leading to problems the following year and especially in 2009. Instead security research is often given incentives to make a discovery look unique (“Download our new ZOMG report now! Try our new anti-ZOMG product!”).

Risk happens. But security can do itself a great disservice if it does not try to take mistakes back to product management and convince them to apply a corrective/new risk formula for the future — breaches should be traced back to decisions whenever possible.

This attack is focused more on a server flaw than prior iterations, which seems innovative, but it still has a lineage.

In other words, if we become too hasty and label a breach as an amazing state-sponsored intelligence effort, we allow vendors to claim it was impossible to see and the cost of prevention too high to achieve (until now, with a handy new ZOMG tool); instead, they would be given less wiggle room and more responsibility for quality engineering if security teams provide a logical progression of warnings and opportunities that showed where they could have fixed the issue much earlier.

Kudos to Zalewski on that account. His post is excellent. I also really like his vendor-neutral recommendations and that he offers defensive suggestions for both server and client.

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