Before I start I have a disclaimer: DISCLAIMER: "PLEASE NOTE I TAKE NO RESPONSIBILITY FOR OTHERS ACTIONS AND USE OF THE INFORMATION FOUND IN THIS BLOG POST, THIS VULNERABILITY IS ALREADY PUBLIC KNOWLEDGE !!!!!!!"
I have been doing some work recently with Silverstripe. Whilst doing some dev work I needed to flush the sites cache which is as easy as appending this ?flush=1 to the end of any url on the site. This got me thinking what would happen if someone sent a bunch of requests to different page on the site with ?flush=1 appended to the url.
So the next thing I did was set a production ready web server VM on my PC and install a traditional LAMP stack, Linux (Ubuntu 12.04), Apache, MySQL and PHP 5.4 (I would of also tested this using Nginx & PHP-FPM but the re-write rule for Nginx don't work and couldn't be bothered stuffing around). Then I downloaded and installed Silverstripe 3.0.5 on the server and got it up and running, I also didn't bother to add any extra content to the default content given by a basic install.
So I did a basic test which was to find out how long a page takes to load when cached and when you flush the cache.
Results:
- Cached Page: 153ms
- Flushed Cache: 940ms
So as you can see the cached page load 8 to 9 times faster. This means there must be a lot happening in the background on the server side.
Next thing was to test to see if I could actually DOS the site, so I wrote a python script which used multiple processes to hit the site with urls that exist and append ?flush=1 to the url to flush the cache.
Basically the script spawns multiple processes that run the attack function which loops forever and hits a random url from a list and appends ?flush=1 to the url.
This script proved to be very effective and it worked as I thought it would.
Then I thought why hell am I able to do this... Other CMS's such as drupal require you to have admin privileges to flush the cache but not Silverstripe. So this is not so much a DOS vulnerability but a security one also because you are giving a user escalated privileges although you can only really flush the cache.
The result of my DOS test were crazy. So when I started the server I had 6 Apache processes running, which is the default, I got up to about 30 processes then ssh died on the web server. So I looked at the VNC console and the system had pretty much crashed and was killing hundreds of Apache processes. And that was only with 50 processes hitting the site and it took about 5 minutes.
Next test was 100 processes which took about 2 minutes to kill the server. Then a 1000 processes which took less than a minute to kill the server.
So after I had my results I proceeded to email the security@silverstripe.org to report the bug as it's as much a security bug as it is a DOS vulnerability. Turned out they have been handling this issue since the 28th of Febuary 2013 and what was more concerning was the fact it was a public ticket on the github bug tracker here.
I hope the NZ Government had Silverstripe pen-tested before the DIA (Department of Internal Affairs) flagged Silverstripe as the CMS for CWP (Common Web Platform).
I have blogged about this because not many people who are running Silverstripe 3 will know about this security bug and the potential threat it has to your website and server.
DISCLAIMER: "PLEASE NOTE I TAKE NO RESPONSIBILITY FOR OTHERS ACTIONS AND USE OF THE INFORMATION FOUND IN THIS BLOG POST, THIS VULNERABILITY IS ALREADY PUBLIC KNOWLEDGE !!!!!!!"
It took Silverstripe 5+ months but a week after my blog post a fix has been merged into master, https://github.com/silverstripe/silverstripe-framework/commit/1298d4a5bd927117f9893f32fd02a75ed10d623b. Good on them but it should of been treated seriously to begin with and had been fixed straight away.
Laters, Christopher Tombleson