AOL Instant Messenger Remote Hole
The DSL Guy writes: "The non-profit security team w00w00.org started off 2002 by uncovering a serious flaw in AOL's Instant Messenger protocol. With over 100 million people registered on the AIM service, this vulnerability poses a serious security risk for Internet users worldwide. This flaw can enable remote users to execute code on any machine logged into the AOL IM service. "So easy to hack, no wonder it's number one!" Details can be found at the w00w00 site."
We recommend Robbie Saunder's AIM Filter (http://www.ssnbc.com/wiz) to protect yourselves. A temporary solution is to go into your Preferences and in the Privacy section click "Allow Only Users on My Buddy List" under "Who can contact me."
Since we all know the holes won't stop here, anyone who wishes to further investigate problems can start their research here and here.
...only windows machines. get your facts straight.
This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.
http://www.w00w00.org/advisories/aim.html is a better link.
Hey, if you guys want open-source IM, check out http://www.jabber.org The server is open-source and it's a distributed XML-based network. Lots of different, cool clients too. JabberIM for Windows, and Gabber for Linux are the most mature ones though. There are bridges to the AIM and ICQ networks available on some servers, but the ones on Jabber.org have been blocked by AOL... nice huh?
The abstract for the article is in error: it reads, "The non-profit security team w00w00.org started off 2002 by uncovering a serious flaw in AOL's Instant Messenger protocol... This flaw can enable remote users to execute code on any machine logged into the AOL IM service.". The flaw isn't in the protocol itself but in the client, and therefore doesn't actually affect "any machine logged into the AOL IM service". It sounds like AOL is going to prevent the sending of exploit packets at the server level to avoid requesting all of their Windows users to upgrade, but those of us using Linux or another OS should be fine regardless.
Love justice; desire mercy.
ALWAYS, if the protocol isn't openly documented and severely tested over a communications line for security it is insecure.
I recommend the majority of people I deal with use jabber (this is not some plug for jabber; it's just at the end of the day, it's more secure and yet accomplishes the same goal AIM etc etc have)
If you are using AIM, do yourself a favor a pickup a jabber client, you won't be sorry.
The problem is in the implementation, not in the protocol. If it were in the protocol, that would make all clients at risk. As it is, only the official Windows client is vulnerable, because it implements game requests without checking for buffer overflow. I really don't understand why people still write code this way -- buffer overflows are so easy to prevent.
Somewhat (but only somewhat) offtopic: why on earth doesn't ./ at leas browse through the links they post? It's not like they don't have the manpower. If they'd even looked at the article, they'd have caught this...
I've recently started using trillian (www.trillian.cc) for all my IMing needs... (yes, it does connect to the AIM server, among others such as MSN messenger, yahoo, and ICQ) I'm assuming it probably doesn't have this flaw, which is obviously a nice feature. And as far as I know, it's the only really solid alternative to a) having a billion separate IM programs b) using hated AOL software.
Once upon a time...
well, here's yet another reason to be using TOC (as opposed to Oscar, the newer of the two AIM protocols.) TOC is/was an open protocol, and i've had very little problem with it. admittedly, it doesn't have all the "features" that Oscar has, but if all you want is chat, and you don't care a whole lot about file transfers, et al. TOC is more than sufficient. plus, unlike Oscar, AOL doesn't seem to arbitrarily change the protocol. And it seems to be more stable, server-side. I've had countless instances of hearing the dispaired cries of "AIM is down" from throughout my dorm without having a problem. TOC goes down occasionally, but not nearly as much, from my experience.
as for clients, i recommend Gaim for Linux. You can select the TOC protocol in the Account Editor window.
<asbestos>yes, i know there's a million things that Oscar can do that TOC can't. but I don't care. TOC just works better from my experience, especially when clients have to release new versions to work around AOL changing the Oscar protocol slightly in order to screw over MS.</asbestos>
#define F(x) int main(){printf(#x,10,#x);}
F(#define F(x) int main(){printf(#x,10,#x);}%cF(%s))
AIM Filter being the program that, if not a trojan, at least has various remote access abilities.
See the bugtraq archive for more information.
Amusing that its use is recommended in the security advisory.
They did wait, AOL ignored them.
We contacted the AOL Instant Messenger group but never received a
response. Normally we would be inclined to provide a fix, but it is
illegal to reverse engineer the AIM executable (DMCA and AIM's license
agreement to thank), so we are unable to provide a patch which will
modify it. Instead, we recommend Robbie Saunder's AIM Filter
(http://www.ssnbc.com/wiz/) to protect yourselves.
Please get the full story before you post shit.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Information security tends to take a far back seat within the corporate world. Doesn't matter if it is management, administration, or development - infosec is a secondary thought if its even considered.
Part of this is the specialized knowledge required to handle infosec issues (not that it couldn't be widely aquired). It takes a concious effort to implement a secure system. This is often considered additional effort. And additional cost.
Another part of the puzzle is a general disbelief anyone could discover a vulnerability and would bother to take advantage of it. This discounts the number of technically minded individuals your infrastructure is exposed to on the net (compounded by automating attacks). It also ignores that even trivial applications can cause considerable damage (I have some friends working infosec for large corporations who went in to high gear with this announcement - AIM exists in many environments).
Finally, infosec is rarely a consumer requirement. Functionality is what sells widgets. Unless the widget is touted as being secure (even IF its supposed to be secure), security won't sell as many widgets if the widgets don't blink and beep nicely. Thus infosec isues are not pushed during initial development.
So now it gets bloody. Damage gets done. Consumers begin to see how these strange little issues cause them pain. They begin to demand better, more secure products. Product goals begin to include infosec. Better products get produced.
And those who would take advantage of vulnerabilities... quietly and to personal gain (or even loudly and publically) have fewer and fewer targets.
And its possible more attention will be paid to those who build faulty, and ultimately dangerous, data infrastructures. Maybe even legal liability.