WP Super Cache 1.4.9

There’s a new release of WP Super Cache out and it’s a security release to fix XSS problems in the settings pages. Those pages are only accessible by admin users so an anonymous visitor to your site can’t come along and enable it to steal your login cookies but along with those fixes come many bug fixes so it’s worth upgrading if you’re using an old version.

From the Changelog:

  • Fixed bug when not running sem_remove after sem_release. See https://github.com/Automattic/wp-super-cache/issues/85
  • Fixed a PHP error impacting PHP 7.1.
  • Fixed a bug where we cached PUT and DELETE requests. We’re treating them like POST requests now.
  • Delete supercache cache files, even when supercache is disabled, because mod_rewrite rules might still be active.
  • Updated the settings page, moving things around. #173
  • Make file locking less attractive on the settings page and fixed the WPSC_DISABLE_LOCKING constant so it really disables file locking even if the user has enabled it already.
  • Added a WPSC_REMOVE_SEMAPHORE constant that must be defined if sem_remove() is to be used as it may cause problems. #174
  • Added a “wpsc_delete_related_pages_on_edit” filter that on returning 0 will disable deletion of pages outside of page being edited. #175
  • Fixed plugin deleting all cached pages when a site had a static homepage. #175
  • Make sure $cache_path has a trailing slash #177
  • Remove flush() #127 but also check if headers are empty and flush and get headers again. #179
  • Add fix for customizer #161 and don’t cache PUT AND DELETE requests #178
  • Check for superglobals before using them. #131

You can click through to each of the Github pull requests above to see discussion around each bug fix.

If you’re hosting many sites that use WP Super Cache and you’re seeing issues with semaphores it may mean that your users are using file locking. It’s really not needed and in #174 there’s a fix that went into this release. You can disable file locking completely by setting the constant “WPSC_DISABLE_LOCKING” in a global configuration file. The file locking simply slowed down how fast cache files were created and is a hold-over from WP Cache when that plugin used to write directly to the cache files. This plugin writes to temporary files before moving to the final cache files so that locking isn’t really needed, but some sites still use it which is why it’s still around.

I’ve already been working on the next release with efforts to move the legacy cache files into the supercache directories. This will make it easier to maintain them and improve performance. We really need to find a better name for this caching method however. It caches everything – page contents and http headers so it’s quite useful!
If you’re going to test that PR, try #176 too. The plugin only deletes index.html type files right now but this chunk of code cleans up various for loops in the plugin and also deletes any file in the named directory. There are some restrictions on it so it won’t delete anything outside the cache directory.

Thanks to everyone who contributed to this release!

WordPress is thirteen!

You could have knocked me over with a feather today when I read Matt’s post announcing that WordPress was celebrating a birthday!

It didn’t seem so long ago that we were working on b2++, hacking the multiuser bits in and doing all sorts of crazy things with it.

Now I’m “typing” this on a mobile phone by swiping my finger across a virtual keyboard. Back then the closest to this that I could imagine would be some sort of SMS integration!

WordPress today is unrecognisable from what it was back then, especially if you use the slick Calypso interface.

I’m looking forward to seeing what the next few years bring.

The Web Won’t Forget Alex King

If you use a WordPress site, either as a visitor or owner, you’re using code that Alex King, one of the original developers of WordPress, worked on.

He passed away after fighting cancer for 2 years but his online presence lives on in the form of his blog with it’s deep archive of posts going back years, and in so much code that it’s humbling to look at his projects page. Looking through the svn log of WordPress trunk shows he still had a hand in helping the WordPress project until relatively recently:

trunk$ svn log|grep alexkingorg
props alexkingorg for the initial, long-suffering patch.
props alexkingorg. fixes #24162.
Props alexkingorg
`wp.media` instead of just `media`. props alexkingorg, see #22676.
Add $post_ID context to the pre_ping filter. props alexkingorg, devesine. fixes #18506.
Add filter so the users can select custom image sizes added by themes and plugins, props alexkingorg, fixes #18520
esc_textarea() and application for obvious textarea escaping. props alexkingorg. fixes #15454
Escape links by default. Props alexkingorg. see #13051
Safely include class-json.php, class-simplepie.php and class-snoopy.php, props alexkingorg, fixes #11827
Fix user creation from admin after changes for #10751. Fixes #10811 props alexkingorg.
Hooks needed to allow alternate category admin inteface. Props alexkingorg. fixes #3408
Wrap cat name in CDATA. props alexkingorg. fixes #3252

I’m sorry I never met Alex, however I remember working virtually with him and Adam Tow on AllThingsD which seems like a lifetime away now. Adam has a great article on Alex on his blog, as does Matt who went into detail about Alex’s involvement with WordPress going back to the days of b2. I had completely forgotten the CSS competition he mentioned!

Alex, your legacy lives on.

WP Super Cache 1.4.5

WP Super Cache is a fast caching plugin for WordPress. It will help your site run faster and serve more traffic.

This is a security and bugfix release.

  • Some servers display a directory index when no index.html is found in a directory. That may reveal the filenames of cache files.
  • There were issues in the settings page that might allow an attacker to browse or delete files named index.html.
  • PHP Object Injection could occur if an attacker managed to inject malicious code into the legacy cache meta files.

When you upgrade, your “legacy cache” files for logged in users will be deleted. This may have an impact on your site:

  • If your site is slow at generating new pages.
  • If you have many known users (logged in users or people who comment).

Your site will suddenly have to generate new cache files for all visiting known users.

Relying on caching like this is not recommended for these types of users as it’s very inefficient. Each user has a separate cache file that must be checked whenever the plugin does administration work like cleaning up stale cache files.

If most of your traffic is anonymous users who don’t comment you don’t need to worry about this.

Directory Listings

If a server is configured to show directory listings it will show files and directories in the cache directory to visitors who access those directories directly through their browser. This might reveal private posts, and in the case where legacy caching is enabled for known users the login cookie was stored in “.meta” files that could be downloaded.

2013

Files named “index.html” were added to the main cache directories to stop remote users viewing the contents of the cache directories. Unfortunately it’s not possible to add empty index.html files to the supercache directories because those files could be served by accident to legitimate visitors of the site. However, the plugin will also add a directive that disables directory listings to the file cache/.htaccess. You can now also change the location of the cache directory on the Advanced Settings page of the plugin. If you can’t disable directory indexing on your server and you have private posts you should change this location and use PHP mode to serve cache files.

cache-location

If a directory index is found in the cache directory it will show a warning like this to administrators:

index.html warnings

Clicking the logout link will log everyone out, except the user who clicks it, but it guarantees that the login cookies are updated, just in case someone has copied the cookie from an old meta file.

Directory Traversal and File Deletion

User input in the settings page wasn’t properly sanitised. The code that sanitised directory paths when deleting cache files wasn’t secure and might allow an attacker to view or delete files named index.html. Deletes are protected by a nonce, limiting the useful lifetime of the URL however.

PHP Object Injection

The plugin used serialize and unserialize to store data in “legacy cache” meta files. This might be used to perform a PHP object injection attack. Serialised data is now stored as JSON data.

The format of legacy cached files has changed. The files in the meta directory no longer have a .meta extension. They are .php files now and each file has a “die()” command to stop anyone loading them.
The data stored in those files is now stored as JSON serialised data. The login cookie is an MD5 hash now as well.
When you upgrade the plugin your existing legacy cache files will be deleted and regenerated as visitors use your site.

Apart from those security fixes there have been a number of enhancements and bugfixes:

  • Disabling the plugin no longer deletes the configuration file. Uninstalling will do that however.
  • Enhancement: Only preload public post types. Props webaware.
  • It’s now possible to deactivate the plugin without visiting the settings page.
  • Fixed the cache rebuild system. Rebuild files were deleted immediately but now survive up to 10 seconds longer than the request that generate them.
  • Minor optimisations: prune_super_cache() exits immediately if the file doesn’t exist.
  • The output of wp_cache_get_cookies_values() is now cached per visit.
  • Added PHP pid to the debug log to aid debugging.
  • Various small bug fixes.
  • Fixed reset of expiry time and GC settings when updating advanced settings.
  • Removed CacheMeta class to avoid APC errors. It’s not used any more.
  • Fixed reset of advanced settings when using “easy” settings page.

This release wouldn’t be possible without the help of Brandon Kraft, Dane Odekirk, Ben Bidner, Jouko Pynnönen and Scrutinizer. Thank you all!

WP Super Cache 1.4.4

WP Super Cache is a full page caching plugin for WordPress. It creates static pages that are served quickly by the web server.

Light Trails in Blarney

Over the weekend there was a flurry of excitement as not one, but two releases of the plugin were made in quick succession. The second to fix a bug introduced in the first. I’m very sorry about that.

WP Super Cache 1.4.3 fixed a security bug in the cache file listing section of the plugin settings page. A carefully crafted query by a third party would cause an XSS in the file listing. While serious, the owner of the blog cannot be tricked into loading the file listing page by way of an image or public link as a nonce is required to load it. The attacker would have to ask the blog owner to visit the cache listing page manually. Thanks to Marc Montpas from Sucuri for reporting that.

WP Super Cache 1.4.4 fixed a bug introduced in the previous version where queries with GET parameters caused a fatal error. Thanks to webaware on the WordPress.org forums for reporting that and including a patch to fix it.

If you’re using an older version of WP Super Cache you’re encourage to upgrade to 1.4.4 as soon as you can.

WP Super Cache 1.4

WP Super Cache version 1.4 is out now. This release finally removes the mfunc, mclude and dynamic-cached-content tags as I warned about three months ago.

If your site uses that dynamic cached content functionality do not upgrade yet. There is a replacement dynamic cached content system but it’s not compatible so you’ll need to update your themes and helper plugins. It’s not difficult but there’s a lot to take in. I hope the example plugin and explanation in that post gets you most of the way there.

If you don’t use mfunc and it’s friends then you should upgrade immediately and it should be painless.

This release also has a few bug fixes and other features. It will now try to repair broken installs after a site migrates. It will update the wp-config.php and rebuild wp-content/advanced-cache.php. It will also delete tags and category cache files when a post publish status changes.