5:20 pm ET September 26, 2007 - New information has been learned since our original publication of this story earlier this afternoon: Two other researchers have been racing to discover either the same or a similar exploit, and their discoveries may have prompted Core Security to make its research public yesterday. Click here for the latest revelations.

In an interview this morning from Buenos Aires with BetaNews, Core Security Chief Technology Officer Iván Arce described a scenario whereby a malicious user could be able to trigger AOL's Instant Messenger into launching Microsoft's Internet Explorer 7 Web browser, and then send it commands that enable that user to wrest full remote control of the AIM user's system.

"The problem here, I think, is not with implementation," Arce told BetaNews. "It's the way this was designed from the start. It wasn't designed thinking about potential malicious inbound messages, so the mechanisms for filtering were not put in the right place."

BetaNews reported yesterday afternoon the first news of the Core Security team's discovery. The reason that AIM 6.1 and the beta of AIM 6.2 can open up the door to Web browser hijacks, Arce told us, is because they use the rendering engine of Internet Explorer for the typesetting of text and graphics, as do many other programs. The use of IE7 for rendering purposes is fully documented by Microsoft, and for years has been a highly desirable option for developers who would rather not reinvent the wheel every time they create an application that renders multiple styles of text with graphics in a window.

"This is functionality that's known," Arce said. "Microsoft has it documented in the MSDN technical reference, it's everywhere, and many applications use it. Because would you rather write your own HTML parser knowing that Microsoft is your target system, or do you use Microsoft's parser, which is already there, tested, and working?"

The documentation also shows the way this should be done safely, Arce added, which is why he insists it's AOL's responsibility to have ensured that AIM uses this connection in the proper way...and that this is not Microsoft's problem. "Unfortunately, AIM didn't do it safely," he remarked, "and they didn't prevent attacks."

What AIM's developers failed to prevent, Arce believes, are two things: first, IE7's functionality becoming exposed - indirectly, though thoroughly - through the AIM peer; second, unnecessary content such as obvious JavaScript instructions from being filtered out before they reach IE7.

"An IM peer can run JavaScript in the target system, and an IM peer can run ActiveX controls in the target system. All of that is functionality that's common for Internet Explorer, but it shouldn't be exposed to a remote peer that is sending an instant message to you," explained Arce.

As his team discovered, a malicious message can be sent to AIM which triggers the Web browser rendering its text to a malicious Web site. Whereas typical malicious messages use more social means to direct victims to malicious sites - for instance, by saying "You won't believe what I just found here..." - Arce found that AIM peers can be sent to malicious sites without any user intervention whatsoever.

Since IE7 is also capable of triggering ActiveX controls, the Core Security team also found that AIM peers can take advantage of that inter-application communication to seize control of the file system, and other Windows services. Or, perhaps more directly, it could simply launch a CMD.EXE window and wreak havoc the old-fashioned way.

"An IM peer could actually run a command shell in the target system by sending a crafted IM with HTML and ActiveX instantiation," he said.

"All of these things stem from the fact that AIM uses Internet Explorer to render HTML, but it doesn't prevent malicious content from reaching the IE functionality. It should be filtering inbound messages and making sure only valid HTML passes through to IE, and it's not doing that." Filters do exist in AIM, however, as Arce's team discovered - they're just not two-way. They filter outbound content only.

"Specifically, the problem in the design is that filtering is being done on the outbound part of the message. It's being filtered out when IM sends the message, not when you receive it. So if I'm a malicious attacker and I find a way to send a message without being filtered, when you receive it, it's not filtered...Obviously, a malicious user could figure out a way to bypass the filter of outbound messages, and therefore all the people receiving the message cannot filter it out."

Next: Is AOL trying to fix this?