Archive for the Flash Category

As you probably know, plugins are external software components which the web browser delegates to render custom content inside web pages, and/or to play audio clips and potentially much more: they actually can do anything, since they're executable code running inside the browser process, with the same privileges as their host. This can cause major security concerns, no doubt about that. They've accumulated lots of security issues of their own over the time, and the scriptable ones (like Flash or Java) are often used in combination with JavaScript to prepare memory for attacks working around protection features deployed by modern OSes. That's why one of the major features of NoScript is blocking plugin content from untrusted web sites, and optionally from trusted too, in an easy "click to activate" fashion: this way you can considerably reduce your attack surface, while retaining the power of accessing plugin content on sites where you really need to.

Add-ons, in mozillaspeak, are a broader category, including plugins of course, but also themes (packages which can change your browser appearance, also called "skins" in other communities) and extensions. NoScript itself is an add-on, or more precisely an extension. Extensions are tiny applications developed with the same technologies which Firefox is made of (i.e. XUL, JavaScript, XPCOM and, possibly but rarely, C++) which upon installation get tightly integrated in the browser, extending (and hopefully enhancing) its functionality. They can access and modify practically any aspect of the browser, and are granted the same privileges as the browser. With great power comes great responsibility, and add-ons are obviously not immune of bugs which can compromise browser security.

There are some differences, though, between extensions and plugins in regard of security:

  1. Extensions which are found to be unsafe can be promptly disabled worldwide by Mozilla admins using a remote centralized mechanism. This is true for plugins too, but I'm very dubious that Mozilla would abruptly kill Flash (or even worse, Java) on all its users in reaction to a zero-day vulnerability disclosure...
  2. Extensions enjoy a safe and very effective update mechanism, which allow security updates to be deployed almost instantly. The same can't be said for most, if not all, the most popular plugins.
  3. The vast majority of Firefox extensions are open sourced. Those hosted on AMO, which is the only place where you can to safely install add-ons from* where Firefox sends you to safely install add-ons, must allow per-policy code reviews, therefore even in those rare cases where native executable code is included, this must comes with its sources, no matter the license. This allows manual screening against malicious extensions (all the hosted add-ons are also automatically scanned by anti-virus software anyway), or more focused security code reviews like the one Wladimir Palant performed recently.

Wladimir is also engaged in a laudable effort for educating extension developers to safer coding practices: whoever maintains or wants to develop a Firefox extension should subscribe his feed.

Coming to "Security Advisers", Roger A. Grimes (a CPA, a CISSP, a CEH, a CHFI, a TICSA, and an MCSE: Security, which in plain English means more or less "security consultant with a strong Microsoft background") recently wrote a serie of articles comparing security features of all the major browsers.

The one about Firefox contained, among others, a quite disturbing (for me at least) paragraph (emphasis is mine):


So I decided to send Roger an email, sparking a pretty intense exchange (in the meanwhile, I was implementing PoC X-Frame-Options compatibility for Firefox with my left hand).

Yesterday I noticed he published a synthesis of our discussion. Even though he cut some logic passages, making our reasoning a bit hard to follow, I have been positively impressed by his openness and I'd like to rectify just two little things:

  1. Roger introduces his report of our thread with these words:

    I indicated that browser add-ons (or plug-ins) could bring additional risk to a browser. One browser add-on provider, Giorgio Maone of Firefox's NoScript, wrote me to strongly disagree.

    As this very post of mine demonstrates, I couldn't and didn't disagree on the concept "that browser add-ons could bring additional risk to a browser". But I was rather surprised (and, honestly, pissed off) about his suggestive exemplification choices.

  2. In an original message of mine, I tried to explain my objection this way:

    You would never dare to say "Mail servers and Web servers, such as qmail and IIS, which come with problems and security issues of their own..."

    I choose qmail for my example because of its almost immaculate security records: should you pick a single product to illustrate mail server security risks, you'd bash Sendmail with its several documented vulnerabilities, rather than DJB's impervious creature. However the article inexplicably morphed "qmail" into GMail, making my point quite obscure (given that GMail is not even a proper mail server, nor exactly a security champion).

That said, I appreciate Roger's transparency and I hope we'll have chances for new constructive discussions.

* Note: JJ Barton correctly made me notice that sites different than AMO can adopt the same hosting security policies (automatic update over a SSL channel, which by the way is required by the Mozilla browser toolkit itself, and possibly blacklisting of unsafe versions), e.g. for the Firebug extension. However AMO is the place where you're automatically directed by Firefox itself when you look for an add-on, so stressing its security features was very important.






Finally NoScript is out, featuring the announced new anti-clickjacking countermeasures enabled by default, independent from IFRAME and plugin content blocking settings.

The most specific and ambitious is called ClearClick: whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in "clear". At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction. This comes quite handy now that more dangerous usages of clickjacking are being disclosed, such as enabling your microphone or your webcam behind your back to spy you through the interwebs.

As you already know if you read my first clickjacking article, an old and benign clickjacking example is NoScript's "Install Now" orange button, which overlays the green one on to work-around the installation security warning. If you click it with ClearClick enabled, now you get warned about something sneaky going on.

ClearClick Warning on NoScript's install button

I do not need to change my button yet, because NoScript ships with ClearClick enabled on untrusted (non whitelisted) parent pages only, while the whitelist status of the embedding is irrelevant. This gives a good balance between effectiveness and usability, since the attacker in a clickjacking attack is always the parent. If you want to get the warning on and on the other sites you trust, you need to flag the second checkbox on NoScript Options|Plugins|ClearClick protection on pages... [x] untrusted [x] trusted. I recommend to flag it anyway and report any usability issue, because this feature so far seems quiet and unobtrusive enough to justify my temptation of enabling everywhere (trusted + untrusted) by default on next stable release, but it must get a lot of testing from you first.


NoScript 1.8.4 and above ship with ClearClick enabled on both untrusted and trusted sites. It works everywhere, even if you've got scripts globally allowed. And yes, at that point I had to change install button, therefore if you want a PoC you need to look elsewhere.

Other clickjacking-related features included in this release are:

  1. Opaque embedded objects: plugin content and frames are forcibly made opaque and get styled with "overflow: auto" (i.e. get scrollbars if their inner size exceed their viewport) on untrusted pages.
  2. Frame Break Emulation: if a framed page which is not allowed to run JavaScript contains a "frame busting" script similar to

    , the intention of the page author is honored by NoScript, i.e. the page replaces the topmost document. You can control this feature toggling the noscript.emulateFrameBreak about:config preference.

  3. Some usability and effectiveness improvements in frame management, making the Forbid IFRAMEs option more suitable for general usage.

I hope to find some time during this week to write another post, diving through the technical details behind my ClearClick implementation: a fairy tale about a very simple and hopeful idea (unconventional <canvas> usage) fighting against an army of quirks and mundane details. In the meanwhile, many thanks to Sirdarckcat, RSnake, Michal Zalewski and Matt Mastracci for discussion, testing and inspiration.

Hurry, it's the best time to use FlashGot Media!


If you did not yet, you should upgrade to NoScript or above, because of the new ClearClick technology, the most effective anti-Clickjacking protection available.

Looks like Clickjacking is the web-security buzzword of the week (month?), since Robert "RSnake" Hansen and Jeremiah Grossman decided to cancel their OWASP talk, drawing an aura of mystery around the whole issue and its magnitudo.

Nevertheless some info and speculations have been percolating, and even if the precise details of the attacks proposed by those two researchers are still embargoed, especially because of the serious and not necessarily obvious implications worrying Adobe, a certain awareness about the general technique and the possible countermeasures does circulate now. In Jeremiah's and RSnake's words:

Think of any button on any Web site, internal or external, that you can get to appear between the browser walls, wire transfers on banks, Digg buttons, CPC advertising banners, Netflix queue, etc. The list is virtually endless and these are relatively harmless examples. Next, consider that an attack can invisibly hover these buttons below the usersâ€™ mouse, so that when they click on something they visually see, they actually are clicking on something the attacker wants them to. [...]
Say you have a home wireless router that you had authenticated prior to going to a [malicious] web site. [The web site] could place a tag under your mouse that frames in a single button an order to the router to, for example, delete all firewall rules.

In other words, the attack is thrown by a malicious web page embedding objects, possibly from a different site, such as framed documents or plugin content (Flash, Silverlight, Java...) which may lead to unwanted results if clicked by the current user (e.g. a "Delete all messages" button in your webmail or an advertisement banner in a click fraud scheme). Using DHTML, and especially CSS, the attacker can disguise or hide the click target in several ways which go completely undetected by the user, who's easily tricked into clicking it in a more or less blind way.

JavaScript increases the effectiveness of these attacks hugely, because it can make our invisible target constantly follow the mouse pointer, intercepting user's first click with no failure. We can however imagine a few less effective but still feasible scriptless scenarios, e.g. covering the whole window with hidden duplicates of the target or overlaying an attractive element of the page, likely to be clicked (e.g. a game or a porn image link), with a transparent target instance.
Nevertheless, as RSnake puts it,

[...] the best defense against clickjacking attacks is to use Firefox with the NoScript add-on installed. Users running that combination will be safe, said Hansen, against â€œa very good chunk of the issues, 99.99 percent at this point.â€

That's true because attacking from an untrusted page not allowed to run JavaScript is highly impractical, but also because NoScript by default prevents Java, Silverlight and especially Flash content, which seem so far the most dangerous clickjacking targets, from being embedded on non-whitelisted pages.

But what about that damned 0.01%? That's given by framed documents, most notably IFRAMEs. For a live and benign example of what you can do with IFRAME-based clickjacking, look at NoScript's "install now!" widget, which gets dynamically overlayed by the install page: they're positioned so that if you click on the orange button you automatically install from AMO, skipping the security notification bar you would get on any other site. This "clickjacking" of mine has been there for a long time (since AMO V3, IIRC), and it heavily relies on JavaScript.

But even if an IFRAME-based attack was carefully crafted to work without JavaScript, NoScript would still provide effective protection, scoring a perfect 100% by RSnake's standards. You just need to enable the Plugins|Forbid <IFRAME> option, and cross-site IFRAMEs will be blocked by default on untrusted pages: they will need a confirmation to be activated, therefore "blind clicks" become impossible. Zone 365 and Hardware Forums created a short video tutorial about this setting. If you want to be protected even against unlikely attacks thrown from a trusted site included in your whitelist, check Plugins|Apply these restriction to trusted sites as well: embedded objects (plugin content and frames) get blocked on every site, but you can enable any of them on the fly by clicking on its placeholder.

A final recommendation is reading this Michal Zalewski's contribution, which covers the IFRAME case only but is very generous with mitigation proposals, both for web developers and browser vendors: by the way, his browser fix proposal #4 is almost identical to current NoScript's Forbid <IFRAME> option, and simpler variants of proposal #3 are being explored as default features in NoScript development builds since version

Bad Behavior has blocked 1932 access attempts in the last 7 days.