Slashdot Mirror


AOL IM 'Away' Message Security Hole Found

thedude13 writes " Infoworld is running a story about a major security hole in AOL ® Instant Messenger(TM) and how it handles away messages. AIM is vulnerable to a buffer overflow via the auto-response away message mechanism. Yet another reason to switch to, IMHO, a better client such as gaim."

7 of 284 comments (clear)

  1. But.... by lachlan76 · · Score: 3, Interesting

    Do many people put links in away messages anyway? Wouldn't people think it was strange that there is a link to something they've never heard about in an away message? I've never used AOL, so can someone tell me if you can use a text link, or is it only a URL?

  2. Coincidental... by GillBates0 · · Score: 4, Interesting
    I've been assigned a task of choosing the best IM service/client for our group at work and will be recommending Gaim (correct capitalization) at a meeting today.

    The decision was mostly because of it's cross-platform, cross-service compatibility and "Buddy Pounce" features (and because it's my personal favorite too :)). This way folks can continue to use their personal MSN/AIM IDs without a problem. The Buddy Pounce feature allows a script/macro to be run in response to an event - this feature is particularly useful for us because we can kick of an SMS message for example in response to a message or another event.

    Though they don't release Solaris binaries, I did get it to build on Solaris/SPARC with a little effort. I know the Yahoo Messenger UNIX version is open source now, so I could probably try and build it for obscure platforms, but it is IMHO severely cripped compared to the Windows counterpart.

    --
    An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
  3. gaim by minus_273 · · Score: 4, Interesting

    seriously is gaim really a better client? It alwasys seems to me like the unauthorized clients are a generation behind the real ones. Back when file sharing was big, gaim could not do it. Then buddy icons, gaim could not do it. No gaim can do those, but the big thing is voice and video, gaim cant do those.

    --
    The war with islam is a war on the beast
    The war on terror is a war for peace
  4. Re:more buffer over flows by Bedouin+X · · Score: 3, Interesting

    I wonder if my newly acquired NX protection (just installed XP SP2) will protect me from this. I use Trillian Pro anyway but if anybody has a link, I'd like to see.

    --
    Dissolve... Resolve... Evolve...
  5. Re:more buffer over flows by Proaxiom · · Score: 4, Interesting
    I don't think it's too much to ask for people who actually get paid to write this stuff to validate input, no matter where it comes from.

    Validating input against assumptions is easy. The hard part is identifying all the assumptions we have to validate against. We often assume things about input without realizing we are assuming them.

    For instance: Not too long ago few programmers had any idea they should check input values for SQL control characters before passing it to a database script. They assumed input wouldn't contain any, without realizing they were so assuming.

    It's true that many bugs arise from unchecked string lengths, and those are usually pretty easy catch (and to fix), but resolving those problems will only take care of a subset -- though probably a large subset -- of the input-related security flaws out there.

  6. Gaim? by illuminatedwax · · Score: 3, Interesting

    I use gaim regularly, but I still haven't weened myself off the official AOL Linux AIM client because gaim still crashes every time I try to send or receive a file. Never have I seen a feature for an OSS program be so seemingly painful and difficult to implement.

    --Stephen

    --
    Did you ever notice that *nix doesn't even cover Linux?
  7. a more secure approach by feepcreature · · Score: 4, Interesting
    I don't think it's too much to ask for people who actually get paid to write this stuff to validate input, no matter where it comes from.

    Validating input against assumptions is easy. The hard part is identifying all the assumptions we have to validate against. We often assume things about input without realizing we are assuming them.

    The more secure approach is not stripping out possibly dangerous input - it is only permitting the minimum necessary. It's not always possible, but it should be applied where possible.

    So if it's a phone number, just numbers (and brackets and a plus for international numbers, and maybe minuses for the transatlantic cousins).

    Naturally there is a tradeoff between security and usability - especially if you make a mistake in the permitted characters :-(

    Even if you're not going that far, anything that looks like an escape character of any sort should generally be banned. Of course, some names have apostrophes, which could look like 'close quotes' if your app is especially dim.

    Just as well there is no strict liability for software bugs!

    --
    Paul "Say no to feeping creaturism"