AOL's AIM is one of the most used IM clients in the world. According to Neilsen/Netratings, AOL had around 53 million IM subscribers in 2006.

A week ago, I've found a critical vulnerability in the latest version of AIM, which could allow an attacker to execute code from remote by simply sending a message to the victim.

Just before reporting the vulnerability to AOL, I've encountered a blog post by Ryan Naraine which describes a vulnerability in AIM that was found by "Shell". After reading the advisory, I understood that this vulnerability is a bit different from the one that I found, as it is in the Notification window which pops-up only when you are not in the middle of conversation with the attacker.

So, I've decided to report the vulnerability to AOL, and provided full description and Proof-of-Concepts. I have yet to receive any response from AOL.

Today, Core Labs have published an advisory which describes the general case of my findings. In the advisory they also claim that AOL has patched the vulnerability, so the latest beta version (v6.5.3.12) of AIM is not vulnerable anymore.

I've tested the PoC which I provided to AOL against the "patched" version. While the latest beta version seems to filter my PoC, I've been able to change my code a little and successfully exploited the vulnerability again.

The problem with AOL's patch is that they filter specific tags and attributes, instead of fixing the main cause of the vulnerability, which is locking down the local zone of their client's web-browser control.

Core Labs describes a workaround in their advisory which messes up with the registry. I think that the common people should avoid this workaround, and stop using AIM until a real fix from AOL will arrive.

I also encourage AOL security staff to contact me as soon as possible. I am willing to provide them with all the new information. I will not contact AOL again, as I'm still waiting for AOL to respond my first email.

[UPDATE:] I've just got an email from AOL which confirms that the "patched" beta version is still vulnerable:

Hi,

We apologize, for not initially responding to your email.  We have already fixed out client on these issues and the client is scheduled for a mid-October release.  This fix is not yet in the current AIM beta client.

Thanks
AOL Product Vulnerability Team

Again, try to avoid using AIM at-least until the mid-October release.

Performing XAS (Cross Application Scripting) attacks automatically (read "no user interaction") is very easy, as I showed before in my "shutting down skype" proof-of-concept.

But, what if you are using a limited web environment, where you can't use iframes or scripts to automate your pwning? Several limited web environments (e.g. blogger.com blog system) does not allow using iframes or script, but they do allow embedding QuickTime movies.

Few days ago, pdp found that it is possible to use QuickTime .qtl files to execute code from remote, when the default browser is Firefox. This is a variant of the good old MOAB #3 and pdp's own MP3 backdooring exploit. It uses a simple "-chrome" command-line switch injection.

As this is a Firefox only exploit, I looked for ways to do the same in Internet Explorer. I found that it is also possible to perform all other noted XAS attacks using QuickTime.

So now, if you are in a limited web environment, you can just embed a .qtl file and conduct an automated XAS attack against the visitor of the web page.

The following is the QuickTime .qtl version of the "shutting down skype" PoC:

An online proof-of-concept in a limited web environment - blogger.com - can be found here.

Fortunately, MySpace were smart enough to finally remove all QuickTime movies from their pages. I hope others will follow them.