Prevent fork bomb

[manuel]

Greetings:

In Wikipedia exists an article (https://en.wikipedia.org/wiki/Fork_bomb) about a fault that affects to Microsoft Windows (I tried it on windows 7 and works), this fault is that the same process can be run many times and consume all system resources.
I imagine that in reactos should happen something similar. My proposal is when a process is run the system check if such process is already running in memory, if exists already many identical processes then might be a fork bomb and reactos then ask the user if authorizes or not to follow running the same process (similar to warning alert in google chrome).

[Konata]

This affects every OS, not just Windows, simply for the fact that limiting the creation of processes is naive and a good way to make an OS non-functional.

Although I guess having some user-controlled way to limit the number of forked processes would be an interesting idea. But, forkbombs are pretty much non-existent, my only experience with one was one I wrote myself for laughs. Nobody's interested in taking down a computer anymore, now it's all about stealing information. Not even my malware-loving friends ever sent me a forkbomb, it's always something that spams files or changes my hostname. Limiting processes sounds a bit frivolous.

Like seriously just because you read a type of attack on wikipedia doesn't mean it's gonna happen. There's malware that runs floppy disks continuously, dramatically diminishing the lifetime of the drive, but when was the last time you caught one of those?

Really I'd be more worried about forkbombs on a server than a desktop OS. Worst case for the latter you just have to restart. Worst case for the former, you encounter downtime and make a lot of customers upset. But even that should never happen unless whatever application you're deploying is that poorly written.

[manuel]

perhaps only a curiosity, but the possibility of that attack exists (I guess that you to a server if it would be a problem), that could be done in this case?

[Z98]

There's no defense against a fork bomb that wouldn't interfere with normal operation. It's why no one bothers trying to defend against it. And there are far easier ways to bog down a system that does not require fork bombs.

[Aeneas]

I do not know how you handle this in Windows, but in Linux there is /etc/security/limits.conf, and BSD knows similar mechanisms.

So yes, it CAN be done.

Then again: Z98 is completely right about interference with the system. I actually once had reached a terribly crashy state of my machine due to setting the limits too low, and really, it is like THE LAST thing on Earth that you would suspect as the cause. It will just make your life harder.

The other thing is: there are MANY ways to crash your system. I discovered once one by chance - something along the lines of:

cat /dev/zero | less

This is going to channel an infinite stream of zeroes into memory, filling it up and crashing.

Want an even easier way? Throw a cup of salt water into an electric connector - the shortening will blow the fuse.

In a word - in my opinion, ReactOS would be better advise to reach a working state rather than trying prematurely to defend against man's insatiable thirst for destruction.

[erkinalp]

That does not prevent us putting a 'Spawn Multiply' ACL permission for executable files as an extension, which would be on by default.

[dizt3mp3r]

Preventing a fork bomb depends how the processes are created, whether they are sub-processes or fully detached processes.

Regardless, the processes will most likely be owned or run under some ownership, normally the owner of the process doing the creating. Each process has a set of quotas/limitations and I expect that user/process quotas such as maxdetach, maxjobs, prclm exist to limit the number of processes that can be created by a user and that system wide limits such as MAXPROCESSCNT exist as a system wide quota to prevent too many overall process from being created. The actual names of these quotas may be slightly different than those I mention but I am sure they or something like them already exists in some form or other.

Direct access to these quotas would be useful.

[Z98]

You're thinking VMS. VMS' functionality has little or no relation to what NT has.

[dizt3mp3r]

I am thinking VMS but I always expect a grown up o/s to have similar structures even if they are buried under a graphical interface. Surely these things exist, that is why I mentioned I'd like to have access to them. I always feel I could do a better job tuning Windows than Windows can do it itself.

[Z98]

As far as I'm aware of, no general purpose OS has that kind of functionality. VMS is of the mainframe pedigree so others of its type might allow for it, but having those kinds of restrictions causes more problems than they would solve in a general purpose OS. The closest you get is something like cgroups in Linux and jails in BSDs, but those are more about constraining low level resources and privilege separation and not about attempting to micro-manage processes.

[jimtabor]

Older OS's allowed a fixed amount of processes to be created. Depending on the type of system, it was at least 32 max.

[Webunny]

Greetings:

In Wikipedia exists an article (https://en.wikipedia.org/wiki/Fork_bomb) about a fault that affects to Microsoft Windows (I tried it on windows 7 and works), this fault is that the same process can be run many times and consume all system resources.
I imagine that in reactos should happen something similar. My proposal is when a process is run the system check if such process is already running in memory, if exists already many identical processes then might be a fork bomb and reactos then ask the user if authorizes or not to follow running the same process (similar to warning alert in google chrome).

Older OS's allowed a fixed amount of processes to be created. Depending on the type of system, it was at least 32 max.

Maybe a combination of both ideas would be workable, like having 64 (or higher) identical processes and from then onwards make it ask authorisation. After all, it's not because Windows don't have that feature that ROS shouldn't have that. Evey weakness reduced is a good thing.

That said, I agree with Aeneas: we'd better reach a working state rather than trying prematurely to defend against this weakness.

[Z98]

In this case, Windows, Linux, and BSDs made the right call to not bother trying to defend against fork bombs because the added complexity far outweighs any supposed gains.

[dizt3mp3r]

http://blogs.technet.com/b/markrussinov ... 61309.aspx

This is a great article by Mark Russinovich - it doesn't help with fork bombs but it does illustrate how the o/s handles process resources. It also makes it quite clear that any process/system limits like those I described in my previous posts don't exist.

The 'older' o/s I was describing allowed an intelligent user to set that limit, once per user, according to the type of job and once per system. It was flexible and easy to set, Z98s comment infers that having such limits that need to be tested/checked slows down the system.

In the 'legacy' days when we compared Unix systems to the comparable VMS system the 'nix systems always came out faster and it is most likely the absence of these controls that allowed 'nix systems to outperform.

[Konata]

Pardon me but I was assuming that process limit wasn't even a security measure, just something to stop the system from using too many resources considering how limited the computer was back then. So that measure wouldn't even have anything to do with forkbombs.

And like Z98 said you really have to look at it practically, there are no foreign forkbombs left out there. The most likely case of getting forkbombed is if someone gets to your machine in person, in which case a forkbomb is the least they could do. Implementing a process limiter would be a huge shot in the foot and good waste of time. If someone was really worried about this, I'd look into making my own software that checks what current processes are active and autokills massively redundant ones. But if you're that paranoid you'd probably feel safer in a single-process environment like DOS (I don't blame you I'm a DOS-loving manic).