OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 3:29 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Fork bombs
PostPosted: Fri Oct 17, 2014 6:30 am 
Offline
Member
Member
User avatar

Joined: Mon Jun 16, 2014 5:59 am
Posts: 543
Location: Shahpur, Layyah, Pakistan
We can crash any multitasking operating system such as Linux or Windows easily with a tiny program by recursive program loading. Pseudo code for myprogram.exe:
Code:
myprogram:
loadProgram ("pathto/myprogram.exe")
goto myprogram

When program runs, computer begins to slow down and crashes.
I think there is no way to prevent it even in Modern operating systems.
What are your opinions to prevent it?


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 7:03 am 
Offline
Member
Member
User avatar

Joined: Thu Aug 11, 2005 11:00 pm
Posts: 1110
Location: Tartu, Estonia
Congratulations for re-inventing the fork bomb.

_________________
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 7:40 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
There are also various approaches like grsecurity that allow the kernel to do resource management: No more than X processes per user, no more than Y forks per minute per user, you get the idea. Not that difficult, actually.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 8:03 am 
Offline
Member
Member
User avatar

Joined: Mon Jun 16, 2014 5:59 am
Posts: 543
Location: Shahpur, Layyah, Pakistan
XenOS wrote:
Congratulations for re-inventing the fork bomb.

I don't know this.


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 8:04 am 
Offline
Member
Member
User avatar

Joined: Mon Jun 16, 2014 5:59 am
Posts: 543
Location: Shahpur, Layyah, Pakistan
Solar wrote:
There are also various approaches like grsecurity that allow the kernel to do resource management: No more than X processes per user, no more than Y forks per minute per user, you get the idea. Not that difficult, actually.

But why these approaches are not used by windows or linux?


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 8:11 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Read the man page on "ulimit".


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Fri Oct 17, 2014 3:06 pm 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
Solar wrote:
There are also various approaches like grsecurity that allow the kernel to do resource management
muazzam wrote:
But why these approaches are not used by windows or linux?
The posted link wrote:
grsecurity is a set of patches for the Linux kernel
It might help if you try and read - or possibly practice your english a bit more if you miss even the basic information presented to you.

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Crashing any operating system with recursion.
PostPosted: Sat Oct 18, 2014 5:33 am 
Offline
Member
Member
User avatar

Joined: Wed Mar 21, 2012 3:01 pm
Posts: 930
That program doesn't crash the operating system. It does the expected: Making a bunch of processes until it fails. Then it keeps trying but likely failing.

This is not a bug in the OS, it is merely a denial of service attack, and a poor one. You can limit memory usage per user if they are meant to share, or just bill users appropriately for their memory usage.


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Sat Oct 18, 2014 6:57 am 
Offline
Member
Member
User avatar

Joined: Mon Jun 16, 2014 5:59 am
Posts: 543
Location: Shahpur, Layyah, Pakistan
Actually, Fork bomb was new term for me.


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Thu Oct 23, 2014 1:02 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
Going through grsecurity's features and configuration options is generally a good idea if you are thinking about "securing" your OS. There are many very good ideas in there; many of them impacting performance, of course.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Fri Oct 24, 2014 8:05 am 
Offline
Member
Member
User avatar

Joined: Mon Jun 05, 2006 11:00 pm
Posts: 2293
Location: USA (and Australia)
I'm coming up with a permission system for applications in my OS.

One permission will be the ability to launch processes.

Another permission will be the ability to execute when it's window is unfocused.

You need to explicit grant an application those permissions (i.e. during install-time). It's not perfect, but it provides a little protection - arbitrary applications can't create processes. If a process if fork-bombing you can just hit the Windows key or something to unfocus it.

_________________
My OS is Perception.


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Fri Oct 24, 2014 8:16 am 
Offline
Member
Member
User avatar

Joined: Thu Aug 11, 2005 11:00 pm
Posts: 1110
Location: Tartu, Estonia
I guess my favored solution would be grouping processes into "jobs", where each job has a limited amount of resources (such as memory, CPU time, maybe slots in the process table etc.). When a process which belongs to a job launches a new process, the child process by default becomes a member of the same job. A fork bomb may thus exhaust the resources of the job, but not of the whole system. Another nice feature in this model would be the ability to kill / abort a job as a whole, including all its processes. This would kill all forked processes of the bomb at once, without any chance for them to fill up freed slots by further forking.

_________________
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Fri Oct 24, 2014 8:58 pm 
Offline
Member
Member
User avatar

Joined: Wed Mar 21, 2012 3:01 pm
Posts: 930
You can always make a more clever fork bomb.


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Fri Oct 24, 2014 10:26 pm 
Offline
Member
Member
User avatar

Joined: Thu Aug 11, 2005 11:00 pm
Posts: 1110
Location: Tartu, Estonia
How would this work, for example, in the case of jobs as I suggested?

_________________
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS


Top
 Profile  
 
 Post subject: Re: Fork bombs
PostPosted: Sat Oct 25, 2014 1:02 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

XenOS wrote:
How would this work, for example, in the case of jobs as I suggested?


Plausible examples may include:
  • maybe you tell a CRON daemon to start 5 copies of you in 2 seconds time
  • maybe you inject key-presses into the keyboard buffer and "exit()" so that if you were started by something like bash then bash gets those key-presses and starts 2 copies of you as background jobs
  • maybe you tell the OS that you're a file system driver for "XYZ file system" and give it a dummy disk image/file (containing several partitions formatted as "XYZ file system") and let the OS auto-mount those file systems (where each of those file systems happen to contain a dummy disk image/file containing more partitions for the OS to auto-mount, which....)
  • Maybe you pretend to be a driver for a USB hub (that has many "virtual USB hubs" connected, that each have...)
  • Maybe your process is used by Apache (via. CGI) whenever someone asks for the web page "http://localhost/foo.html", where your process asks Apache for the web page "http://localhost/foo.html" itself.
  • Maybe it's just a simple trojan thing - e.g. "This game needs fork permission so the client can start a server process for single-player games"
  • Maybe there's a way to trick the GUI into thinking that the user clicked on the "OK, let this process have fork permission" button in the dialog box; where the application's installer clicks the button before the user has time to see it


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 26 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group