Fork Bomb on Adobe Campaign: A Controlled Test
It was around 10 years ago when I first encountered the term ‘fork bomb’. I tried it, it worked, and it made me happy that my virtual server went down quicker than a lightning strike. And that was it – my fork bomb adventure back then. After all these years, I don’t know why I got the same idea years later. Instead of a shell script, I will try to program my very own fork bomb on the Adobe Campaign Classic application server to see that lightning strike again.
Shall we begin? BEWARE: The text below contains falling servers!
What is a fork bomb?
A fork bomb is a malicious computer program designed to create a large number of processes, overwhelming the system and causing it to slow down or crash. The term “fork” refers to the Unix system call used to create a new process. The fork bomb continuously replicates itself by initiating new processes, consuming system resources and depleting the available computing power.
The fork bomb does not typically cause damage to files or data but can render a system unusable by exhausting its resources. It’s considered a form of denial-of-service attack because it denies legitimate users access to the system by making it unresponsive.
It’s important to note that creating and deploying fork bombs or engaging in any form of malicious activity is unethical and potentially illegal. Responsible use of technology and adherence to ethical standards are crucial in maintaining a secure and respectful digital environment.
This should only be attempted in personal sandboxed environments where you have full access to restore the system to its previous state or deploy server backups.
So that said we all know that this should not be run at any of circumstances unless you want to cause unwanted problems and later be held responsible for them. I did run it for so you do not have to.
Anyway, let’s build one to see what happens when we run it (I mean we already know it). First, we need to understand how to create multiple processes or running threads inside the Adobe Campaign Classic environment. And what better thread can we find than a workflow that will serve our sweetly malicious intent?
We can assume that one workflow running equals a single process or thread of an application that executes.
How to build a fork bomb
Armed with this information, we simply need to create a workflow that, when run, generates two more workflows and executes them. These newly created workflows will each run an additional two workflows. And then the same repeats until we make our server go 500 – Internal server error. You can get the image right?
I won’t provide the exact steps, but you already have the idea of how to set it up and simple search or previous experience will tell you how to deploy workflow with using JSAPI. Now, let’s explore what happened when I ran it on my virtual private server.
The aftermath of the fork bomb
Here we are—I initiated the fork bomb, and it didn’t take long for the graphs to go wild. My CPU is maxed out, and my console connection is broken with nice internal server error. Which meant the fork bomb took over the resources successfully. Is this the end of the story, or is there more to come?
My provider’s ‘automated-black-box-to-me-server-tools’ soon realized something was off and stopped Adobe Campaign services. Shortly after, all the graph metrics returned to normal. Bless them engeneers who figured things out.
Anyway, with the queue not cleared, you might have guessed what happened after the application server started again. It began running all queued workflows, each with the sole task of deploying themselves and causing CPU congestion otherwise known as fork bomb.
Mitigation of the fork bomb
How do we mitigate when a fork bomb occurs? While the chance of intentional occurrence is small, there’s a possibility of unintentional infinite loops or loops that may not crash the server instantly but can significantly slow it down. This happened to me, and I understand the impact.
Adobe Campaign lacks checks for infinite loops, especially in email personalization. To mitigate, one option is to remove all ‘infected’ workflows with a queued status, identifiable through the SQL console on the server level. Alternatively, for a simpler but data-loss-incurring solution, you can restore the server from the backup. I successfully restored my server using the user interface provided by my hosting provider, and Adobe Campaign was back to its peak performance in a short time.
