Bad Idea Jeans Week: Building a Fork Bomb in SQL Server

Somewhat different than a sex bomb, a fork bomb is a denial-of-service attack that just starts a process that replicates itself, thereby starting more and more processes until the service goes down. Wikipedia’s fork bomb page lists examples on most operating systems (including Windows).

I’ve always found fork bombs funny because of their elegant simplicity, so I figured, why not build one in SQL Server?

In order to do it, I needed a way to spawn a self-replicating asynchronous process, so I built:

  1. A stored procedure
  2. That creates an Agent job
  3. That runs the stored procedure

So it just infinitely runs itself, spawning more and more Agent jobs as it goes. It’s just seven lines:

Run that stored proc just once – WHICH YOU SHOULD NEVER DO, but I know how you people roll and you’re going to go try this in a VM, just like I did – and the result is rather spectacular: within seconds, SQL Server creates thousands of Agent jobs, and they’re fighting for CPU resources:

Beggin for threads
Beggin for threads

Seriously, you shouldn’t try this on a VM you ever want to keep again, but if you want to try this trick repeatedly, this Stack answer on deleting Agent jobs will come in handy. To recover, stop both SQL Server and Agent, then start SQL Server without starting Agent.

I’m using a global stored procedure here to limit the damage for fun and games, but if you really wanted to see some explosions, you could:

  • Create the stored proc in a user database, or as a permanent object in TempDB
  • Add a line to call msdb.dbo.sp_add_schedule to run this job on startup
  • Add additional lines in here to run more queries, such as this little gem that randomly creates GUID-named tables in each user database and inflates them
If you ever needed a reason as to why you shouldn’t allow untrusted people to be sysadmin or manage SQL Agent jobs, this is probably a pretty good post to bookmark. You can do a hell of a lot of damage with less than ten lines of T-SQL.

Wanna watch me run this live, plus a few other stunts? Check out the recording of the Watch SQL Server Break & Explode webcast from Dell DBA Days.

Previous Post
Bad Idea Jeans Week: Prevent the Use of the Database Engine Tuning Advisor
Next Post
Bad Idea Jeans Week: Dynamically Generating Long Queries

14 Comments. Leave new

  • Thanks, I needed a massive SQL crash script. This should work wonders. Now to put some resource limits on the VM so it doesn’t kill my laptop.

  • Is Erik going to post how he broke SQL Server using the DBCC WRITEPAGE command :). That was really fun to see what damage that did. If that were a bad idea jean, would it be cutoff jorts?

  • Actually I can see a real use for this Testing DBAs on the use of the DAC. Throw this on a VM and then tell your DBA to fix it without rebooting. You are almost going to have to use the DAC.

  • You’d be tempted to think that the Resource Governor would afford some protection if you classify your agent jobs so they don’t consume all of your CPU? However, when Kendra was out here last year she didn’t sound too impressed with this feature and seemed to indicate it doesn’t actually behave that way? Have you guys already blogged on this?

    • Chris – depends. Have you actually done that? If you’ve done it, then you’re safe. If you’re just learning about this now through our blog…then no, you’re not safe. 😉

  • That’s really a lot of damage that you can do with this kind of fork bomb. Especially figuring out what’s happening would be the hardest part I guess.
    My suggestion would be to immediately shut down SQL Server Agent. Of course this could not be taken as a general recipe…but if the company doesn’t rely on SQL Server Agent for critical business processes and things are already that worse…wouldn’t that be a way to go?
    Could I then use the stored procedures as well to delete the job or would I have to do some deletes on MSDB tables?

    What do you think about this?

    • Martin – I’ll turn those questions around on you. What do YOU think about that? I did the work of writing the post already. 😉

      • Well Brent…sorry for not reading thoroughly….as you have written yourself “To recover, stop both SQL Server and Agent, then start SQL Server without starting Agent.”

        I don’t see a reason why stored procedures like sp_addjob or sp_deletejob shouldn’t work without having the SQL Server Agent enabled. And I have just confirmed that it works. Interestingly it throws an informational message “SQLServerAgent is not currently running so it cannot be notified of this action.”.

        In an ideal situation a DBA would also think of his/her backup jobs running through SQL Server Agents and find a replacement such as a sql batch with an infinite loop and an WAIT FOR DELAY command to mimick different executions.

  • ah, I wish I could convert that into MySql. to try it on my setup. Is it possible to do on MySql servers?

  • Could you do something similar with a loopback linked server? That would remove the dependency onSQL Agent


Leave a Reply

Your email address will not be published.

Fill out this field
Fill out this field
Please enter a valid email address.