TL;DR: AOL wanted to stop third-party clients from accessing the AOL Instant Messenger network. It did so by intentionally exploiting a buffer overflow in the official AOL client to perform remote code execution. Third party clients presumably were programmed more safely and/or didn’t want to open themselves up intentionally to RCE and thus would fail this “authentication”.
Whereas nowadays we have to download and run proprietary binary blobs in order to view Web content that we’ve already paid for. But only on approved browsers and OSs, of course. Which come with ads and spyware baked in.
It’s a platform almost entirely built on open standards with a few limited exceptions, sandboxed by default, doesn’t suffer from “buffer overflow of the week” (they still exist, but not as much as in the 90s), and is cross-platform and runs on pretty much anything. Yes, I’d call that an improvement over some Windows-only .exe file with a known buffer overflow as a “feature”.
If you’re annoyed with widevine DRM: yes, it’s annoying. But most of the web functions perfectly fine without it – only Netflix, Spotify, and similar services don’t. It’s not ideal but also not that big of a deal.
Note that it relied on jumping to a “call esp” instruction which is not normally generated in executable code; the byte sequence happened to be in a bitmap resource. I’m curious whether this exploit would work on Vista and up - once the CPU/OS implements NX, that bitmap would not normally be executable, so the process would crash before executing the payload. It’s possible to mark any section of a PE as executable, but this would not be done by default for a .rsrc section, so they’d need to specially mark executables to be vulnerable.
There’s a much longer sordid history here. Back in the early 2000s instant messaging was a big thing, the social media of its time, and there were several competing networks. AOL Instant Messenger was big, if not the biggest, and through tricks like this was locking others out. Creating a monopoly.
When AOL merged with Time Warner (lol) one of the requirements from the anti-trust judge was that AOL agree to allow interoperation between its IM product and others, notably MSN. This made perfect sense to us in the industry; it’s how email worked, for example. It was a condition of allowing the AOL/TW deal to go through.
Did AOL ever fulfill that legal obligation? No. They dragged their feet and kept inventing legal excuses and thanks to the Bush Administration were never really held to implement the agreement. In the meantime IM sort of spiraled into oblivion as a product category (thanks in part because of the lack of interoperability) and AOL/TW went to shit for many other reasons.
Unfortunately this debacle set a big precedent that tech companies could simply ignore US government requirements meant to protect competitive markets.
When AOL merged with Time Warner (lol) one of the requirements from the anti-trust judge was that AOL agree to allow interoperation between its IM product and others, notably MSN. This made perfect sense to us in the industry; it’s how email worked, for example. It was a condition of allowing the AOL/TW deal to go through.
Fascinating. It seems like an early predicissor of the interoperability debate currently going on in the EU. Do you have a source where I can continue reading about this?
Yeah, the IM wars were an interesting time. It was part AOL vs. Microsoft, part AOL vs. Trillian and gAIM (nowadays called Pidgin).
A couple years later, in 2001, they took a different tack: rather than exploiting the client, they just added a new protocol message that let the server request the client to read an arbitrary chunk of its own executable and send back the MD5 hash. If the client ignored the message, or sent back an incorrect hash, it got disconnected. The idea there being similar to some of the copy protection that Sony and Nintendo did back in the day — anything that could pass the test would have to have a copy of the AIM binary, at which point AOL could sue for unauthorized distribution under copyright law.
TL;DR: AOL wanted to stop third-party clients from accessing the AOL Instant Messenger network. It did so by intentionally exploiting a buffer overflow in the official AOL client to perform remote code execution. Third party clients presumably were programmed more safely and/or didn’t want to open themselves up intentionally to RCE and thus would fail this “authentication”.
Software in the 90s/early 00s was such a wild west cowboy show.
Whereas nowadays we have to download and run proprietary binary blobs in order to view Web content that we’ve already paid for. But only on approved browsers and OSs, of course. Which come with ads and spyware baked in.
Things are so much better in the 2020s …
It’s a platform almost entirely built on open standards with a few limited exceptions, sandboxed by default, doesn’t suffer from “buffer overflow of the week” (they still exist, but not as much as in the 90s), and is cross-platform and runs on pretty much anything. Yes, I’d call that an improvement over some Windows-only .exe file with a known buffer overflow as a “feature”.
If you’re annoyed with widevine DRM: yes, it’s annoying. But most of the web functions perfectly fine without it – only Netflix, Spotify, and similar services don’t. It’s not ideal but also not that big of a deal.
How do you know that there aren’t similar horrors lurking inside that proprietary blob?
Note that it relied on jumping to a “call esp” instruction which is not normally generated in executable code; the byte sequence happened to be in a bitmap resource. I’m curious whether this exploit would work on Vista and up - once the CPU/OS implements NX, that bitmap would not normally be executable, so the process would crash before executing the payload. It’s possible to mark any section of a PE as executable, but this would not be done by default for a .rsrc section, so they’d need to specially mark executables to be vulnerable.
There’s a much longer sordid history here. Back in the early 2000s instant messaging was a big thing, the social media of its time, and there were several competing networks. AOL Instant Messenger was big, if not the biggest, and through tricks like this was locking others out. Creating a monopoly.
When AOL merged with Time Warner (lol) one of the requirements from the anti-trust judge was that AOL agree to allow interoperation between its IM product and others, notably MSN. This made perfect sense to us in the industry; it’s how email worked, for example. It was a condition of allowing the AOL/TW deal to go through.
Did AOL ever fulfill that legal obligation? No. They dragged their feet and kept inventing legal excuses and thanks to the Bush Administration were never really held to implement the agreement. In the meantime IM sort of spiraled into oblivion as a product category (thanks in part because of the lack of interoperability) and AOL/TW went to shit for many other reasons.
Unfortunately this debacle set a big precedent that tech companies could simply ignore US government requirements meant to protect competitive markets.
Fascinating. It seems like an early predicissor of the interoperability debate currently going on in the EU. Do you have a source where I can continue reading about this?
I’m sure a lot was written about it, particularly during the merger, but I don’t have it at hand. Here’s one article though: https://www.nytimes.com/2001/01/12/business/fcc-approves-aol-time-warner-deal-with-conditions.html
Thanks!
Yeah, the IM wars were an interesting time. It was part AOL vs. Microsoft, part AOL vs. Trillian and gAIM (nowadays called Pidgin).
A couple years later, in 2001, they took a different tack: rather than exploiting the client, they just added a new protocol message that let the server request the client to read an arbitrary chunk of its own executable and send back the MD5 hash. If the client ignored the message, or sent back an incorrect hash, it got disconnected. The idea there being similar to some of the copy protection that Sony and Nintendo did back in the day — anything that could pass the test would have to have a copy of the AIM binary, at which point AOL could sue for unauthorized distribution under copyright law.