Recall the Time Before, when AOL was based on a DOS/GeoWorks client for most users? I heard some stories about the totality of access they had to those clients that were scary.
The guy telling me this story had some credibility from his work history; and an astounding collection of candid amateur porn and "famous people data". Every journalist used SideKick to keep their contacts, apparently. Fun times.
There were persistent stories, then; that AOL officially scraped clients for addresses to send "free Trial" disks to. Those were officially denied. They carefully didn't talk about what employees might be able to access "on their own" and didn't ask much about where their "prospect" mailing lists came from, either.
There are so many easier sources to get names and addresses I’m really skeptical they would be scraping address books just to send out their plastic waste/advertisements.
I was into direct mail at the time; $0.10 per deliverable address was the going rate for "random" lists. They weren't after that, though; they wanted not just computer owners but modem owners at first and that kind of filtering was hard to find and expensive. I had ~3,500 true gold known modem owner addresses, my dude gave me several hundred dollars of trade value for it.
They were very eager to buy lists at less than the going rate that were better than random. Later they got less selective, modems could be assumed. Then about the time Win 3.1 happened they got truly spammy.
Whoever thought not fixing a remote code execution bug just so they could use it to do something as trivial as tell the difference between their client and others should have been fired.
after the Microsoft attack started is when we started looking for any defense we could find. The fact that the enabling instruction was in the running man icon seemed to be a sign that it was ok.
Since the client code we wrote only talked to the server code we also wrote, the security standards were a bit looser. Host code would never have a bug like this; the host side was constantly attacked by hostile clients and just routers that bit flipped in weird places; overflow bugs would have happened and would have triggered a crash, core dump, and bug fix right away. But the client team was a lot more product / feature driven and constantly rushing.
If someone had stood up an alternative host endpoint then this would have been a bigger issue, but I think the attacks were only other clients logging into our hosts. Tho there is now a group trying to recreate the host complex I have heard.
We did patch the bug and replace the buffer overflow with a new “send us the checksum or hash or this range of virtual memory” which was as good for stopping attacks. They could have shifted to a client that ran the real client invisibly and controlled it thru windows API but they didn’t
Clarification: the "Microsoft attack" was: they made a legitimate client that was compatible with your server's protocol? The effect of which was users didn't have to download the AIM client and also didn't see AOL ads?
Correct. A classic Microsoft embrace and extend attack. They took out many (potential) competitors during the 90s with similar free as in beer software.
As far as legitimate goes, I think it was soon rendered against the TOS of the person logging in, tho I don’t find TOS to be a particularly useful concept or practice.
Microsoft also gave away http clients and http servers and it cost humanity a lot (for a while) that those attacks succeeded.
Now google is attacking by again giving away free software and using their monopoly money to attack competitors.
And for the ads, development keep an arbitrary 64k limit on ad sizes so they couldn’t be giant multimedia monstrosities.
Hey, thanks for your reply. :) From your comment history, and your use of the word "we," I'm wondering: are you the person I just said should have been fired? Lol
No I was host side, the person that thought of the overflow was a client dev, the very person that wrote the sloppy code.
I always use we when talking about this job because it was a good group of very smart developers that I learned a lot from, not because I personally merit the reflected glory.
I like modifying future versions of the client to produce similarly useful behaviour deliberately though, seems like a reasonable "apply evil hack, turn into less evil hack as soon as possible" sort of approach to the situation.
I always considered them letting Excel use undocumented APIs but making the documented APIs a PITA to use for Lotus 1-2-3 one of their dirtiest tricks.
> Users are then to download and install the AIM client software, which AOL does not charge for
I suspect if this sentence was written today, the author would not mention the download was free. In fact, they would only mention the price if the download wasn't free.
It's an interesting change in expectation where in the 90s there was far more of an acceptance/expectation to paying for software as compared to today. I suspect Google changed expectations with Gmail (it provided an order of magnitude more storage for free compared to paid email providers), but that's only a guess. I would be interested in learning more about how the consumer expectation changed over time.
I’m certain AOL had a Mac client in the 1990s, but I’m not sure when the first Mac AIM was released. This exploit wouldn’t work on the Mac version, because Macs at the time were 68000 and PowerPC-based, so it seems quite short-sighted to depend on i386 exploits for client identification.
I think these shenanigans were mainly to counter 3rd parties from connecting to AIM. MSN tried to very briefly, I think, but AOL attacked GAIM (now called Pidgin) consistently for years.
JOOI: the author of the piece is the same person who uncovered Microsoft's AARD code that made Windows 3.1 fake failing on DR-DOS.
Former AOLer here. It was to stop Microsoft. This was the third time Microsoft tried to take out AOL. They tried saying that they were running on MacOS earlier but in that case TCP fingerprinting was added to the Mac client logging path and windows looks different from Mac at the TCP layer. Sequence numbers if I recall.
We didn’t feel it was bad to buffer overflow our own code, since it was client code we wrote in the first place. Later client versions had some sort of “checksum this range of virtual memory and return the checksum” and the buffer overflow fixed.
As far as GAIM the dev team didn’t care about that, and efforts to stop it were pretty much half hearted, if I recall. We ended up hosting an end point “toc.oscar.aol.com” to let things like the TCL client and the elisp client work. We couldn’t convince people to release the protocol specs for the full Oscar protocol unfortunately.
https://slashdot.org/story/01/01/25/1343218/directvs-secret-...