Prevent fork bomb

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

manuel
Posts: 411
Joined: Thu Jan 28, 2010 11:20 pm
Location: México
Contact:

Prevent fork bomb

Post by 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).

User avatar
Konata
Posts: 391
Joined: Sun Apr 20, 2014 8:54 pm

Re: Prevent fork bomb

Post by 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
Posts: 411
Joined: Thu Jan 28, 2010 11:20 pm
Location: México
Contact:

Re: Prevent fork bomb

Post by 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
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Prevent fork bomb

Post by 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
Posts: 470
Joined: Sat Oct 10, 2009 10:09 pm

Re: Prevent fork bomb

Post by 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
Posts: 860
Joined: Sat Dec 20, 2008 5:55 pm
Location: Izmir, TR

Re: Prevent fork bomb

Post by erkinalp »

That does not prevent us putting a 'Spawn Multiply' ACL permission for executable files as an extension, which would be on by default.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2

User avatar
dizt3mp3r
Posts: 1627
Joined: Mon Jun 14, 2010 5:54 pm

Re: Prevent fork bomb

Post by 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.
Skillset: VMS sysadmin 20 years, fault Tolerance, cluster, Vax, Alpha, ftSparc. DCL, QB45, VB6, NET, PHP, JS, CMS, Graphics, Project Manager, DOS, Windows admin from 1985. Quad Electronics. Classic cars & motorbikes. Artist watercolours. Historian.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Prevent fork bomb

Post by Z98 »

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

User avatar
dizt3mp3r
Posts: 1627
Joined: Mon Jun 14, 2010 5:54 pm

Re: Prevent fork bomb

Post by 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.
Skillset: VMS sysadmin 20 years, fault Tolerance, cluster, Vax, Alpha, ftSparc. DCL, QB45, VB6, NET, PHP, JS, CMS, Graphics, Project Manager, DOS, Windows admin from 1985. Quad Electronics. Classic cars & motorbikes. Artist watercolours. Historian.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Prevent fork bomb

Post by 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
Developer
Posts: 229
Joined: Thu Sep 29, 2005 3:00 pm

Re: Prevent fork bomb

Post by 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
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: Prevent fork bomb

Post by Webunny »

manuel wrote: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).
jimtabor wrote: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
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Prevent fork bomb

Post by 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.

User avatar
dizt3mp3r
Posts: 1627
Joined: Mon Jun 14, 2010 5:54 pm

Re: Prevent fork bomb

Post by 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.
Skillset: VMS sysadmin 20 years, fault Tolerance, cluster, Vax, Alpha, ftSparc. DCL, QB45, VB6, NET, PHP, JS, CMS, Graphics, Project Manager, DOS, Windows admin from 1985. Quad Electronics. Classic cars & motorbikes. Artist watercolours. Historian.

User avatar
Konata
Posts: 391
Joined: Sun Apr 20, 2014 8:54 pm

Re: Prevent fork bomb

Post by 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).

Post Reply

Who is online

Users browsing this forum: learn_more and 1 guest