Slashdot Mirror
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))
rooooar
Eg Europe, where reverse engineering is explicitly legal regardless of any terms and conditions the software vendor may seek to impose.
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.
What this product manager did not realize was that, despite w00w00's "white hat" e-mail, w00w00 wasn't on their side or even their users'; w00w00 wanted to embarrass the company.
They sure as hell *did* want to embarrass AOL, and you know why? Because telling people something gets things done! If w00w00 had elected *not* to tell AOL, this bug could have been sitting out there for many months to come, and by the time AOL finally did decide to fix it, it could have reached epic proportions.
Well let's see. The situation went from a few dozen (hundred?) people being able to exploit an obscure hole to hundreds of thousands knowing how in detail.
But most boxen on which AOL is run are on narrowband connections, on the less powerful of the Windows operating systems, and turned off most of the time. Any exploitation (beyond vast compromise, which would likely be picked up by AOL staff) would be for little more than just making trouble.
Think about it: even if deployment of a bug fix hadn't been slated for another month, all w00w00 accomplished was a dramatic increase in AOL's (and AOL users') damage exposure. They did the self-righteous thing.
OK, let's do some rough math right now. Say that yesterday, J. Random Cracker found this m4d AOL exploit. He would prolly relay it to his friends to show how 1337 he was through (most likely) IRC. Assuming that he's on a fairly good-sized IRC channel, 20-50 people learn about the exploit right there. It spreads in much the same way throughout the "hacker" underground, and within hours, hundreds of thousands of l33t h4x0rz all know about the exploit and begin using it on hapless AOL users (few, if any, of whom are running any server daemons). This will go on until:
a) The magnitude of the traffic is large enough to show up on AOL's collective radar,
b) An attacker suddenly gets a pang of conscience and reports the exploit to a security firm, or
c) A computer with sufficiently robust security gets hit (either by the attackers' AOL exploits or attacks launched from the compromised computers), the admin notices, investigates, talks to AOL, gets logs, and reports the exploit to a security firm.
In any case, the collective exposure is a good deal more than what w00w00 has restricted it to (the collective malicious-user traffic to their site and the mass media for a period of one day, if AOL is to be believed). They didn't do the self-righteous thing, they did the honest thing.
Want Linux games? HERE.