hackademix.net

Yesterday Adobe rushed out a security update (version 10.1.85.3), one week in advance on the announced schedule, patching a critical vulnerability that has being exploited in the wild for more than one week.

As usual, users of the latest stable Firefox version on Windows are plagued with an awful manual update process, involving the installation of a ridiculous “Adobe DLM (powered by getPlus(3))” extension (forcing an extra, useless, browser restart), whose only function seems to be displaying additional banners during the download.

Even worse, this time looks like Adobe made going through this process actually impossible, on my system at least, because of a mismatch between the DLM plugin version they automatically offer, i.e. getPlusPlus for Adobe 16290, and the version actually required for downloading the Flash update with their markup:

<embed type="application/getplusplusadobe16291"
pluginspage="http://platformdl.adobe.com/NOS/getPlusPlus/1.6/gp.xpi"
service-url="http://get.adobe.com/flashplayer/webservices/dlm/"
return-page="http://get.adobe.com/flashplayer/completion/dlm/"
itemid="Flash_Player_10.1_for_Windows_-_Other_Browsers"
core-product="flashplayer" dlmbanner="on" language="" os="" height="1" width="1">

As you can see, the required version is 16291, rather than 16290.

Fortunately the actual direct download URL is not impossible to discover, for instance by dinamically replacing “16291″ with “16290″ with a bit of javascript: magic in the address bar and sniffing the network activity.

So, if you’re stuck like me or you just don’t want to install this getPlusPlus crap, you probably want to use this direct link :)

The Adobe Flash Player, current version 10.1.82.76 and below, is affected by a critical vulnerability which, according to Adobe’s Security Advisory APSA10-03, is being actively exploited in the wild. A patch won’t be available until September the 27^th, which means the 3 or 4 Flash users out there are left in the cold, under attack for two weeks at least.

In the meanwhile, the only mitigation measures available are either disabling Flash outright or using NoScript.
At any rate, relying on the “FlashBlock” extensions for your security is not a good idea, neither on Firefox nor on Chrome: these toys are great against annoyances, but too easy to circumvent to be hacker-proof. Unfortunately you can always find naive advices in the press…

If you believe that building your whitelist of websites trusted to run scripts is too tiresome, please consider this: after 2 or 3 days of training, NoScript will know enough about your browsing habits to amost vanish in the background. Moreover, latest versions feature a true “one click” UI which further reduces your initial effort, because now the contextual menu is shown as soon as you just hover over NoScript’s icon, allows you to switch multiple permissions at once and disappears as your mouse moves away. However, if you’re an irreducible who wants JavaScript to run free everywhere, you can still emulate a safer “FlashBlock mode” by using NoScript’s (not recommended) Allow Scripts Globally command after having checked NoScript Options|Embeddings|Apply these restrictions to trusted sites as well.

Talking about mitigation, I heard much fanfare (even on ./) about Microsoft’s Enhanced Mitigation Toolkit (EMET) 2.0 being able to prevent exploitation of another 0 day affecting Adobe Acrobat Reader. Unfortunately at this moment I had no success at downloading this fabulous tool by following the available links, but this probably just means I’m low on caffeine. Could anybody point me to a working and trusted EMET 2.0 download source? Update: the link from the MS blog was actually broken this morning, but now it’s reachable as pointed out by a commenter.

Update 2010-09-20

Adobe rushed out version 10.1.85.3 one week earlier than scheduled to patch this hole.

Michael Coates just announced that X-Frame-Option will be finally available on Firefox starting with the next minor update, 3.6.9.

This is great news, because it puts vanilla Firefox on par with IE and Chrome regarding this server-side defense, which security-aware web authors (like the guys at Google, and possibly the AMO team now) can use, by modifying the way their pages are served, in order to protect their web sites against frame-based Clickjacking.

I said “vanilla”, because Firefox with NoScript has been supporting X-Frame-Options since the day after it had been announced with much fanfare by Microsoft, i.e. Jan the 29^th 2009 (more than 1 year and half, now). Mostly as a point of pride, actually, than out of a true necessity, since the existent NoScript’s ClearClick module already provided a more complete and effective protection against all kinds of Clickjacking (either frame-based or plugin-based), independently from the good will and security awareness of server-side implementers.

It’s worth to mention that in many situations, like on web properties which provide some kinds of frame-based APIs, or support external apps and “widgets”, X-Frame-Options is hard or impossible to be configured properly, because it would break the business model of the site itself. Facebook is a glaring example of this kind of sites, vulnerable to Clickjacking, where X-Frame-Options would fall short. Needless to say, NoScript’s ClearClick does protect against Clickjacking everywhere, no matter if web site owners could not, or choose not, to implement X-Frame-Options (or just didn’t know about it!).

To be fair, there’s an upcoming Firefox 4 technology which can better help web developers protecting their web sites against this and other web application security issues, even in complex scenarios like Facebook’s: it is Content Security Policy (CSP). I’d really love it to get popular enough among security-aware developers, and possibly be standardized across browser implementations.

On the other hand, as long as you don’t trust every web site out there to always do the right thing security-wise, NoScript will be your friend :)

Classic ASP is the old server-side web scripting technology based on VBScript, now superseded by ASP.NET, which lots of developers, including myself, learned to hate in the nineties when, for mysterious reasons, a certain customer decided he needed the whole “Enterprise” Microsoft 3-tiers stack (IIS/COM+/SQL Server). Luckily enough, nobody asks you to build anything new using ASP these days (even though there’s always some insanely unmaintainable VBScript code out there which badly needs maintenance), but this technology, albeit agonizing, yet found a way to come back and make me sad again.

Some days ago this blog post, talking about a bypass method for NoScript’s Anti-XSS filter, called for my attention (not thanks to its author).

Even though it’s not very clear from that piece of writing, the issue at hand is quite simple but, in my opinion, outrageously stupid and annoying. I’m gonna call it “HomoXSSuality” (even though most LGBT people I know is neither simple, nor stupid nor annoying), because homoglyps and homophones conspire to make XSS (and SQL injection) attacks easier to pull.

Like any other server-side web programming framework, ASP gives developers some means to extract “parameters” (name/value pairs) from the HTTP requests, stored either in the query string or in the POST data. For instance, if an ASP script is invoked using the URL http://some.site.com/my_heroes.asp?name=Giorgio%20Maone&hero=%E1%BD%99%CF%80%CE%B1%CF%84%CE%AF%CE%B1, parameters can be extracted by code like this:

At runtime, the Name variable will contain “Giorgio Maone”, while Hero will be set to “Ὑπατία“. This contrived example show also how “special” characters, such as space or Greek alphabet letters, are escaped by standard percent encoding, i.e. by taking the UTF-8 hexadecimal representation of the string and prefixing each byte with a “%” character: specifically, “ ” translates to “%20”, and “Ὑπατία” to “%E1%BD%99%CF%80%CE%B1%CF%84%CE%AF%CE%B1″. This is the translation you can obtain from the encodeURIComponent() ECMAScript function, and the recommended way of escaping URLs.
An older and never standardized method, implemented by the now deprecated JavaScript escape() function, produces more or less the same output for ASCII strings, but uses the UTF-16 representation prefixed with “%u” for higher (beyond ASCII) Unicode strings: for instance, “ ” still stays “%20”, but “Ὑπατία” becomes “%u1F59%u03C0%u03B1%u03C4%u03AF%u03B1″.

NoScript’s Anti-XSS filter, while processing HTTP requests, does recognizes and properly handle both these encoding styles, and many more. Any web security filter should be able to do it, because web applications usually consume data that has been automatically decoded by their runtime environment.

But Classic ASP adds a perverse twist to its parameter decoding routines. The Request() API apparently assumes that developers and/or browsers and/or users are too stupid to handle non-ASCII Unicode characters (e.g. greek alphabet letters) by themselves, thus it tries to protect them from such execrable things by automatically translating any non-ASCII character into the ASCII counterpart which resembles it the most; when no suitable replacement can be picked, with either “?” or “�” (arbitrarily, it seems). So “%u1F59%u03C0%u03B1%u03C4%u03AF%u03B1″, rather than “Ὑπατία”, becomes a quite ugly “?pat?a”. As you can see, while the replacement choice is mainly homoglyphic (α→a, τ→t), it may also follow homophonic criteria (π→p).

To figure out the whole range of Unicode-ASCII transliterations performed by ASP, I needed to write an ad hoc program mixing VBScript and JavaScript, and I also used it to automatically generate the ASPIdiocy.js mappings file that can be found in recent NoScript packages.

A short essay here, to give you just a taste of this madness:

(0x100) ~= A(0x41)
ā(0x101) ~= a(0x61)
Ă(0x102) ~= A(0x41)
ă(0x103) ~= a(0x61)
Ą(0x104) ~= A(0x41)
ą(0x105) ~= a(0x61)
Ć(0x106) ~= C(0x43)
ć(0x107) ~= c(0x63)
Ĉ(0x108) ~= C(0x43)
ĉ(0x109) ~= c(0x63)
Ċ(0x10a) ~= C(0x43)
ċ(0x10b) ~= c(0x63)
Č(0x10c) ~= C(0x43)
č(0x10d) ~= c(0x63)
Ď(0x10e) ~= D(0x44)
ď(0x10f) ~= d(0x64)
Đ(0x110) ~= �(0xfffd)
đ(0x111) ~= d(0x64)
Ē(0x112) ~= E(0x45)
ē(0x113) ~= e(0x65)
Ĕ(0x114) ~= E(0x45)
ĕ(0x115) ~= e(0x65)
Ė(0x116) ~= E(0x45)
ė(0x117) ~= e(0x65)
Ę(0x118) ~= E(0x45)
ę(0x119) ~= e(0x65)
Ě(0x11a) ~= E(0x45)
ě(0x11b) ~= e(0x65)
Ĝ(0x11c) ~= G(0x47)
ĝ(0x11d) ~= g(0x67)
Ğ(0x11e) ~= G(0x47)
ğ(0x11f) ~= g(0x67)
Ġ(0x120) ~= G(0x47)
ġ(0x121) ~= g(0x67)
Ģ(0x122) ~= G(0x47)
ģ(0x123) ~= g(0x67)
Ĥ(0x124) ~= H(0x48)
ĥ(0x125) ~= h(0x68)
Ħ(0x126) ~= H(0x48)
ħ(0x127) ~= h(0x68)
Ĩ(0x128) ~= I(0x49)
ĩ(0x129) ~= i(0x69)
Ī(0x12a) ~= I(0x49)
ī(0x12b) ~= i(0x69)
Ĭ(0x12c) ~= I(0x49)
ĭ(0x12d) ~= i(0x69)
Į(0x12e) ~= I(0x49)
į(0x12f) ~= i(0x69)
İ(0x130) ~= I(0x49)
ı(0x131) ~= i(0x69)
Ĵ(0x134) ~= J(0x4a)
ĵ(0x135) ~= j(0x6a)
Ķ(0x136) ~= K(0x4b)
ķ(0x137) ~= k(0x6b)
ĸ(0x138) ~= ?(0x3f)
Ĺ(0x139) ~= L(0x4c)
ĺ(0x13a) ~= l(0x6c)
Ļ(0x13b) ~= L(0x4c)
ļ(0x13c) ~= l(0x6c)
Ľ(0x13d) ~= L(0x4c)
ľ(0x13e) ~= l(0x6c)
Ł(0x141) ~= L(0x4c)
ł(0x142) ~= l(0x6c)
Ń(0x143) ~= N(0x4e)
ń(0x144) ~= n(0x6e)
Ņ(0x145) ~= N(0x4e)
ņ(0x146) ~= n(0x6e)
Ň(0x147) ~= N(0x4e)
ň(0x148) ~= n(0x6e)
Ō(0x14c) ~= O(0x4f)
ō(0x14d) ~= o(0x6f)
Ŏ(0x14e) ~= O(0x4f)
ŏ(0x14f) ~= o(0x6f)
Ő(0x150) ~= O(0x4f)
ő(0x151) ~= o(0x6f)
Ŕ(0x154) ~= R(0x52)
ŕ(0x155) ~= r(0x72)
Ŗ(0x156) ~= R(0x52)
ŗ(0x157) ~= r(0x72)
Ř(0x158) ~= R(0x52)
ř(0x159) ~= r(0x72)
Ś(0x15a) ~= S(0x53)
ś(0x15b) ~= s(0x73)
Ŝ(0x15c) ~= S(0x53)
ŝ(0x15d) ~= s(0x73)
Ş(0x15e) ~= S(0x53)
ş(0x15f) ~= s(0x73)
Ţ(0x162) ~= T(0x54)
ţ(0x163) ~= t(0x74)
Ť(0x164) ~= T(0x54)
ť(0x165) ~= t(0x74)
Ŧ(0x166) ~= T(0x54)
ŧ(0x167) ~= t(0x74)
Ũ(0x168) ~= U(0x55)
ũ(0x169) ~= u(0x75)
Ū(0x16a) ~= U(0x55)
ū(0x16b) ~= u(0x75)
Ŭ(0x16c) ~= U(0x55)
ŭ(0x16d) ~= u(0x75)
Ů(0x16e) ~= U(0x55)
ů(0x16f) ~= u(0x75)
Ű(0x170) ~= U(0x55)
ű(0x171) ~= u(0x75)
Ų(0x172) ~= U(0x55)
ų(0x173) ~= u(0x75)
Ŵ(0x174) ~= W(0x57)
ŵ(0x175) ~= w(0x77)
Ŷ(0x176) ~= Y(0x59)
ŷ(0x177) ~= y(0x79)
Ÿ(0x178) ~= �(0xfffd)
Ź(0x179) ~= Z(0x5a)
ź(0x17a) ~= z(0x7a)
Ż(0x17b) ~= Z(0x5a)
ż(0x17c) ~= z(0x7a)
〈(0x2329) ~= <(0x3c)
〈(0x3008) ~= <(0x3c)
＜(0xff1c) ~= <(0x3c)
ʹ(0x2b9) ~= '(0x27)
ʼ(0x2bc) ~= '(0x27)
ˈ(0x2c8) ~= '(0x27)
′(0x2032) ~= '(0x27)
＇(0xff07) ~= '(0x27)

As you can see in the end, I could list 3 different homoglyphs for < (less than, ASCII 0×27) and 5 for ' (apostrophe, ASCII 0×3c). Anybody with a bit of familiarity with XSS or SQL injection has already guessed where I’m going…

Classic ASP translates the query string parameter value %u3008scr%u0131pt%u3009%u212fval(%uFF07al%u212Frt(%22XSS%22)%u02C8)%u2329/scr%u0131pt%u232A to

which, if echoed back, is executed as a JavaScript block by web browsers.

Any “sane” web server runtime (either a recent IIS with ASP.NET or Apache with PHP/Python/Ruby, or a Java Servlet Container, or you pick yours) either leaves the %u… stuff alone (because this escaping style is deprecated), or translates the whole into

which obviously has no other meaning than “funny text”, to any decent web browser.

This undocumented (AFAIK) Classic ASP “feature” (which was sooo good and smart that Microsoft itself dropped it in ASP.NET) can severely screw up with any anti-XSS filter. It does with Google Chrome’s, it does not with Microsoft IE8’s (unsurprisingly, since the original mess came from Redmond), it does not anymore with NoScript’s, since version 2.0.2rc2.

Of course, it may also be used to bypass Web Application Firewalls (WAFs), which, ironically enough, are often deployed to “virtually patch” XSS and SQL injection bugs in hardly maintainable applications, just like the ones developed with Classic ASP: this blog had been just created when it witnessed a tragicomic case involving the United Nations.

So, how many WAFs out there can actually resist when HomoXSSuality calls?

Changes are coming at an incredibly fast pace on Firefox trunk, and since NoScript is, among extensions, one of the most entangled with the browser’s internals, you may expect its stable version to break fairly often.

That’s what happened a couple months ago with some incompatible XPCOM registration changes, and what is happening this week with the new asynchronous redirection API.

In both cases, the breakage has been fixed in a very short time (few hours at most) by a NoScript development build. To be fair, the most recent issue required no more than 1 minute of coding (plus build and deployment times) to be fixed for the “average” client of the redirect API, e.g. Adblock Plus, but NoScript is also an implementation — or vice-versa, depending on the point of view: the sense is that NoScript both uses and exposes this API, by mimicking fake HTTP redirects as part of its ABE and HTTPS enhancements inner workings, so the fix has been a bit more complex.

However, the bottom line is that if you’re on a Minefield (Firefox development build) or a Firefox beta, you should really use a NoScript development build: they’re updated automatically and very often through AMO’s “Beta” channel, they don’t display release notes on startup unless a new stable version has been released in the meanwhile, and they’re the version used by me and my colleagues (plus lots of beta testers) for our daily browsing, thus it’s guaranteed not to get broken by any showstopper bug for more than one hour at most.

Of course, if you find any bug yourself please report it in the forum ASAP, thanks.