Testing Fork Bomb

Note: This post will take some time to load because of videos and the fact that this blog is running on a tiny server. I will switch to a high config instance soon enough.

I wanted to mess around with “fork bomb” and see what kind of damage it does as well as try to understand what it actually does.

I will be running it on different linux distributions as well as windows WSL and if possible, on windows itself. Buckle up, as we embark on a sweet DoS journey!

For those unaware

Fork bomb is a bash one liner, whose sole purpose is to overload the entire system and eventually crash it. The way it works is it keeps replicating a single process as quickly as possible, exhausting all the resources of a system thereby making it unusable.

It’s very easy to understand if you have worked with bash scripts in the past. Let’s break it down:

:(): defining a function named “:”. it could be any other name but it won’t work on different versions of bash.

{ }: opening and closing for the function

:|:: the real deal is this bad boy. it calls the function recursively and then passes its output, using a pipe, to the next function, which is also the same function. essentially, it calls a function twice.

&: this one is just sending those processes in the background

;:: ending function definition and calling it again

Action time

I spun up an Ubuntu VM on a proxmox instance. It has the following config:

I will let it run for around a minute and see if the system shuts down on it’s own or if it stays up.

I tried to run glances (htop GUI) for a broader overview of the system resources but unfortunately it gets killed rather quickly.

The CPU spikes up very quickly but the RAM takes some time to fill up. After some time, the CPU usage goes around 50-70% which is weird. It was still unusable during the entire time.

Let’s try it on alpine:

What? Alpine is immune to fork bombs? Well, they are using a different shell called ash, which is slightly different than bash.

For some reason, the name of the function cannot be a colon. Therefore, we just have to change it to something else, let’s make it hello().

It’s quite similar to ubuntu instance. RAM takes some time while CPU goes up instantaneously. Onto WSL and windows.

WSL and windows

Even after giving a lot of resources (4 cores and 10 gigs of RAM), it is using almost half of it on idle. I realize now, on why I stopped using windows years ago. It was a good choice.

On the other hand, windows server 2022 is less resource intensive and works really well on low config.

Windows becomes a bit choppy, but is still usable to some extent. The WSL instance is obviously oblierated and doesn’t respond.

On the task bar, we see “Vmmem” taking the highest resource usage. What’s that? I couldn’t find any official documentation regarding it but there is some general information about it.

It’s a process which is used to allocate resources to the VMs

And the last one in our testing phase is windows.

%0|%0

%0 is the name of the currently executing batch file. %0|%0 is going to recursively execute itself forever, quickly creating many processes and slowing down the system.

Seems like windows is able to withstand it.

That would be the end of this post. Keep experimenting!