|
So, let's continue on the logical path of the author. If I take a big hammer and hit my PC, will Windows be able to predict and prevent such activity? Well, here you go.
Alex.
|
|
|
|
|
http://computing-dictionary.thefreedictionary.com/fork+bomb
|
|
|
|
|
Microsoft intended that its developers should utilize the APIs and the documentation. They also outline behaviours or guidelines which should be strictly adhered to. This however does not mean that one has to. As a point, the operating system is generally stable when all programs follow these guidelines, but Microsoft was not hell-bent on policing programmers.
As many have commented, there are several ways which you can restrict your own application. My favorite method is using a Mutex, as MSDN outlines as a method of limiting an applications process. You can use recursive iteration of Mutex names to allow multiple (but not infinite) instances.
Looking at the documentation on MSDN also points out that WinExec is an obsolete function provided for 16bit compatibility and is surpassed by CreateProcess.
I have not greatly exhausted the possibilities by any means. You could even go to such great lengths as to write a data file to track concurrent executable, but this and pretty much anything else is not necessary.
I don't see any reason to write a recursively executing application other than for a virus, in which case the programmer perhaps is not concerned with its negative side-effects.
For any general purpose, the programmer should use good judgement as to how these situations should be handled, or even avoided.
~Emyos
|
|
|
|
|
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)
{
char* pszThisModule = new char[MAX_PATH + 1];
GetModuleFileName(NULL, pszThisModule, MAX_PATH + 1);
char* pszSystemPath = new char[MAX_PATH + 1];
DWORD dwLength = GetSystemDirectory(pszSystemPath, MAX_PATH +1);
char szReplicantName[16] = "\\replicant.exe";
if(dwLength < MAX_PATH - 16)
{
strncat(pszSystemPath, szReplicantName, MAX_PATH);
}
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
|
|
|
|
|
"If you are interested in any custom programming or would be interested in collaberating on a joint project"...
Please remain at HTML "programming". Don't quit your full-time job over this new C/C++ thing
|
|
|
|
|
Funny. People would rather bash someone than help them out. The maturity level has obviously dropped to a new low.
|
|
|
|
|
Hey, what if i'd like to do so?
Windows can't prevent me for doing this.
- - - - - - - - - - - - - - - - - -
Memory leaks is the price we pay \0
01234567890123456789012345678901234
|
|
|
|
|
Firstly, I think this is comming up as a issue due to WindowsNT/2Ks origins as a single user O/S. Unix variant all have resource limits which can be applied on a user by user basis. Nothing sh*ts me more about NT based systems than the fact that the O/S doesn't put the TaskManager priority to max and all other processes to min when TaskManager is executed. I'm the admin dammit and I want responsiveness
Secondly some comments on your code, which if you post it you can't whinge about people commenting on it;
1) Why do you copy the exe file? It's completely unecessary to illustrate your point.
2) Sometimes you use the MS sanctioned Hungarian naming convention, sometimes you dont? Bad style.
3) WinExec is deprecated ( 16bit only?) CreateProcess is preferred.
4) Your while loop control logic is really strange.
Finally, using a batch file could show your point much more dramatically
:loop
start notepad.exe
goto loop
Cheers
L
|
|
|
|
|
*grins* To get the proper fork bomb effect you really want your .cmd file to be something more like this:
@start %0 & start %0
Do save your work before you try it, though personally I found under XP I could still get enough responsiveness to start taskmgr and choose End Process Tree on the root.
Alternatively, being ready to delete the .cmd file is likely quicker.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
I don't get your whole article. no os can run an infinite amount of applications. spawning applications in a loop will end up thrashing your system no matter how much memory you have. so you wrote a fork bomb.. big deal. you can fork bomb most oses. if your case was that the os should somehow intelligently deny the creation of process you probably have a point and i'm sure the os would gladly comply if you gave it the permission to (which you won't considering you're hell bent on taking it down)
|
|
|
|
|
|
I agree also. This is hardly a problem. If a user had access to run any program he wanted, there would be any number of denial of service attacks possible.
The solution isn't to make Windows (or any OS) not allow this, It's just to make Windows allocated a certain amount of resources to a given user.
|
|
|
|
|
yeah - this isn't a flaw at all. this 'flaw' exists on every operating system
|
|
|
|
|
yeah but u can fix it on linux and BSD only on windoze can u nnot fix it
|
|
|
|
|
i agree, too!
and anyway, you do not have to compile a fork bomb! all you have to do:
(in cmd)
echo start go.bat > go.bat
go.bat
(in cmd)
it is a one-line batch file which will bomb your system
if you want a faster kill, in 2 lines:
(batch file - go.bat)
start go.bat
start explorer.exe
(batch file)
this could be fitted onto one line, using & or &&
to make the kill even faster, keep adding 'start explorer.exe' to the end of the file
Yours,
Jerome M.P. Baum
|
|
|
|
|
I really don't understand the reason of critisizing an author, based on the content you don't agree with... If you don't agree -- just ignore and have a life!!!...
Is it necessary to respond, if you don't like something???
C'mon, please, be at least intelligent!!!...
====================================
As to the point of the article:
I myself, absolutely disagree that OS should provide any checks against BAD program behavior... It's responsibility of the program designed for a specific OS to perform that...
However, there is an interesting question, that would be nice to get an asnwer to from .NET Gurus???...
Assuming, I'm starting .NET exe from some extranet site... And that .NET exe start executing the code logically equivalent to the code described by that article... Does that mean that CLIENT will be dead???? If so, what the reason of HIGH LEVEL SECURITY in .NET if that simple spawning deadlocks the client???
Interesting to hear any anwer???
|
|
|
|
|
Microsoft does include the appropriate sort of support for handling fork bombs and such. Go read up on job objects on MSDN.
Server code that needs to manage/balance the resource usage of other unknown code should use these API's.
You seem to be suggesting that the windows shell itself should prevent you as the user from running more processes than are good for you. Do you think it should also prevent you from choosing ugly colors or using annoying sound schemes as well?
All in all, this article is clueless Microsoft bashing. Other's have already pointed out how broken the example code is.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Ok...now that's being blatently rude. As far as I know, a ugly color scheme or an annoying sound scheme can't crash your system. And let's see...a fork bomb could??? Yeah, I think that's right.
As for my code, yeah, it's not perfect, but it gets the point accross, a point which you've apparently failed to grasp.
Can you imagine Darth Maul on speed?
|
|
|
|
|
No no, that wasn't rude at all... give me a moment to get warmed up.
I'll try to stick to small words here, pay attention and think about how these impact your 'point'.
~ Windows provides job control objects. (The fact that you don't know about them only indicates that you need to read more before you spout off, not a flaw in the design of the OS.)
~ These job control objects allow the launching code to constrain all of the resources consumed by a process and anything else it launches in turn. (Forking and is only one of many ways an application can cause denial of service problems.)
~ While it is important for some process launching environments to prevent the applications they start from consuming too many resource, this is not the place of the shell in a single user environment.
~ By comparision Terminal Services supports administrative interfaces to do exactly this sort of limits, so people sharing a machine can't impact each other.
~ You are clearly an inexperienced kid who doesn't understand these distinctions.
~ Clueless but willing to learn is always acceptable. Agressively clueless is not.
-Blake (turning up the rude dial a little bit)
|
|
|
|
|
Ok...let's take a step back here for a second. if this would have been said in a kinder way and offered as help and not appearing so much like bashing me personally as I am still learning alot about, then I woudl have been inclined to respond in kind. if I took your critisism the wrong way, I apologize.
Now on to issues of coding style and proper methods in which to code. After some reading as many haev suggested, I've discovered that job objects do perform this function on the more recent flavors of the windows OS ( 2000, XP, etc.) Since I'm running on win98 ( yes I'm that poor ) I don't have access to be able to utilize job objects in my code unless there is an SDK somewhere that I'm not aware of that enables this functionality for windows 98. I've been told that an alternative is the uses of mutexes, but alas I'm not familiar with their usage and will endeavor to read up on them. If you could offer any insight into their usage, I'd apprecaite it, but I'd ask out of respect that you not bash me for my inexperience. I made teh mistake of writing a "misinformed" article on the subject of WinExec Process execution, and will gladly clean it up once I've gained the knowledge to know what to do to prevent it from happening.
Can you imagine Darth Maul on speed?
|
|
|
|
|
A very measured response, thank you.
None of the DOS-based versions of Windows support job objects (or large numbers of other important advanced APIs.) This isn't surprising given their history and design goals. Anyone and any code on those platforms has complete control of the machine for better or worse.
Mutexes (and other related interprocess synchronization primitives) are supported under Win9x, but they serve a different purpose. Those sorts of API's are what you might use to limit the resources consumed by a group of co-operating processes. (A semaphore rather than a mutex has counting semantics, if that's what you are looking for.) To be clear though, none of these will help you prevent some other unknown code from wildly consuming resources.
There isn't any good way to do that under Win9x. Some possible bad ways would involve the toolhelp and/or debugging APIs - but for the effort involved there an upgrade to XP would be cheaper.
Is there a specific case where you've had something fork-bomb accidentally rather than with intentionally malicious code?
regards,
-Blake
|
|
|
|
|
When does a program gets called 'fork bomb'?
If it opens 2 instance of itself? 3? 10? 15? 200? 300000?
Of course your program keep starting instances, but
the OS don't know if a program will do that or stop itself after a predefined number of instances.
What if i wrote an AI or a Biological simulation program
and need to run 1000 instances of itself?
- - - - - - - - - - - - - - - - - -
Memory leaks is the price we pay \0
01234567890123456789012345678901234
|
|
|
|
|
Windows doesn't need more 'access control' for the CreateProcess call, because this just isn't a problem in practice. Besides that, look up 'fork bomb' and learn that this is hardly a Windows-only issue.
This article should win some sort of prize for 'most flaws and outright bugs in a single page of code'- check out that while loop condition for the best example. Also, what's with all the dynamically allocated filename buffers? And why bother making a copy of your executable before spawning it? Error checking? Etc, etc. I bring these items up only because of the article's comment about making the code 'complete and correct', which it most certainly is not.
OK, I understand you're a C++ newbie, but until you have a better handle on the language and OS you should probably be reading articles (lots of articles) rather than writing them. Good luck!
--
Eric
Move along, nothing to see here.
|
|
|
|
|
The whole point in copying the executable is the fact that for each executable generated the effect of the while loop is exponentiated.
As for my dynamicly allocated buffers, excuse my obvious stupidity in making sure to have buffer overflows in my code. I'm sure someone woudl want to exploit a buffer overflow in an already malicious piece of code
The whole point of this article which you haev obviously failed to grasp is the fact that windows as well as whatever other OS's that allow forking shoudl have some kind of method for limiting teh amount of dulplicate executables running at any given time.
Thank you for replying anyways. I feel I've returned as much tact and decency as you've displayed to me. Ciao.
Can you imagine Darth Maul on speed?
|
|
|
|
|
John Aldrich wrote:
excuse my obvious stupidity in making sure to have buffer overflows in my code
No comment necessary.
Anyway, another poster pointed out that Windows does in fact provide job objects that do what you apparently want.
--
Eric
Move along, nothing to see here.
|
|
|
|