Archive for December, 2007

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 hi5.com 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.

java&
#x73;cript:
\u0061\u006c\u0065\u0072\u0074\u0028\u0022
\u0048\u0061\u0070\u0070\u0079 " + 0×07D8)

John Resig (of jQuery fame, now a Mozilla Corp. employee) lets us know that JSON leakage through Array constructor redefinition, one form of so called AJAX-hijacking working on Opera, Safari and Firefox, is going to be impossible on Firefox 3.
Starting with next Beta 2, in facts, most built-in global constructors (

Array, Boolean, Date, Math, Number, Object, RegExp, String

) will be constant: override attempts will raise an error.
This is obviously an incompatible change, even though the “broken” functionality shouldn’t be something you rely upon in your everyday web application.
Anyway, if you find any regression, this is currently tracked under Bug 376957.

The 3ivx high performance MPEG-4 audio/video codec (MP4) for Microsoft Windows is vulnerable to stack overflow, with shellcode proof of concept published by SYS 49152 (a C64 nostalgic like me, undoubtedly).
Surely affected versions are 4.5.1, quite widespread, and the latest 5.0.1.

The most likely exploitation scenario involves user downloading a movie clip in MP4 format from an untrusted source (did you say p0rn?) and consuming it through a media player which relies on the 3ivx codec (the PoC above exploits Media Player Classic, for instance).
Notice that the file name extension doesn’t need to be “.mp4″, as mp4 streams can be wrapped inside container formats such as ASF or AVI.
Of course, if the vulnerable media player installed also its own browser plugin, you can be owned instantly just stumbling upon an untrusted web page, unless you already took proper countermeasures.

How to protect yourself

  1. Open your Windows Control Panel.
  2. Select Add or Remove Programs.
  3. Locate the 3ivx D4 entry, select it and click the Remove button.
  4. Optionally, if you couldn’t locate any 3ivx D4 item, check if you’ve got
    3ivx.dll

    and/or

    3ivxVfWCode.dll

    in your

    %WinDir%\System32\

    folder; if you can find these files, delete or rename them.

If you still need to play MP4 files and you find your system can’t do it anymore, you may want to install the excellent open source VLC Media Player, which uses a different codec.

Slop… er… happy surfing ;)

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.

Update:

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.

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