Silverstripe 3 DOS vulnerable

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

  • Guest

    This is a setup problem with the sites, if the sites are set in live mode you need to be logged in as admin.

    To set your site to live mode set this in your mysite/_config.php file
    Director::set_environment_type(“live”);

    • chtombleson

      Good to know.

      There is still a question of why this is implemented in it’s current form, as this is a pretty obvious problem and should of been avoided in the first place.

      I like Silverstripe it’s a good solid CMS but little things like this make me double think about running it production.

      Also you could use mod_rewrite to work around this problem and possibly restrict its use to certain IP addresses.

  • micmania1

    Have you fixed this yet?

  • sminnee

    Hi Chris,

    Thanks again for raising this issue with us and digging in more detail into its effects.

    I can see that it would be concerning to find that a DoS issue you had raised had already been logged in our bug tracker and not yet resolved. Ultimately, when the issue came to our attention we had rated it as not a severe issue, and so we prioritised it alongside other issues for resolution. This impacted the urgency with which we addressed it. There were a few reasons for that. Firstly, a server configured with a lower MaxClients won’t be as susceptible to a full DoS of the server from this bug – the server would be up although responses would slow down, and the offending IP address could be blocked. It’s not ideal, but it would be manageable in the case of an attack via this (which, to our knowledge, has never happened). Also, there is no information disclosure or control an attacker would get from flushing a site: the flush is intended to be able to be called at any time without affecting the functioning of the site. That, combined with the fact that the fix wasn’t trivial to make, led to the issue being still open at the time you started your investigation.

    As for how the issue got into the system in the first place: when it was originally developed, the scope of the flush command was much more limited and the performance impact was not great enough to be a DoS target. It was a toss-up as to whether we would execute the functionality automatically by detecting the necessary changes, and in the end decided to make it manually triggered. That changed over time as the script behind it got more weighty, and now we need to solve it.

    But that’s all in the past. What’s important now is that we fix the issue and put it out there for people who may be affected. The fix is almost complete and we will release security updates for 2.4 and 3.0, as well as including the fix in 3.1-rc1 (imminently awaiting release) and providing patches for people to apply the fix themselves. In the meantime, Hamish has put together some workarounds that you can apply here: https://github.com/silverstripe/silverstripe-framework/issues/1692#issuecomment-21151232

    It’s not for me to comment on the details of DIA’s security testing of CWP, apart from saying that there has been a robust, independent process underway in the lead-up to its launch.

    Thanks,

    Sam Minnée
    CEO
    SilverStripe Limited