Friday-evening, time to pretend you’re a young hipster! And this might help; a great (old, as in over 10 years old) track called “Manila” by Seelenluft in the Manitoba remix, as it was featured in Four Tet’s magnificent “Essential Mix” from way back in 2010;
De kerken lopen leeg, maar pakweg 5 keer in een mensenleven (doop, eerste communie, tweede communie, huwelijk en dood) speelt de Katholieke Kerk toch een onmiskenbaar grote rol in het leven van veel gelovige en zelfs ongelovige Belgen (en Fransmannen en Spanjaarden en …). Soit, Michel had het er al uitgebreid over, dus dat moet ik hier niet meer doen.
Het is maar wat je er zelf van wilt maken, wat voor jou zinvol is. Indien je gelovig bent en geboorte, trouw en dood in en met de Kerk wilt vieren, fantastisch. Maar als dat niet écht zo is, denk dan even na over de alternatieven. En contacteer eventueel het “Huis van de Mens” om te praten over hoe jij zelf zin kunt geven aan die grootse momenten in het leven?
There’s real gems to be found on KCRW’s YouTube channel, which features artists that perform live in the studio. Laura Mvula is a upcoming UK vocalist and you can see her performing “Sing To The Moon” below. Enjoy!
Laura Mvula performing "Sing To The Moon" Live on KCRW
Now that both WP Super Cache and W3 Total Cache developers have released a new version of their respective plugins (upgrade first, continue reading after) it seems time for a small “post mortem“.
The problem was in the interpretation ofdynamic snippets, that are contained inside a number of specific HTML-comment tags. These snippets allow both plugins (and their predecessor WP Cache) to cache pages while keeping a limited amount of dynamic, PHP-generated content in them that can be executed on the fly. Think ESI in e.g. Varnish.
Unlike ESI’s, dynamic snippets can not only be includes (mclude) but also PHP-code (mfunc). Whereas one could consider includes of known files more or less safe, inclusion of PHP-code introduces a risk.
As WP Super Cache & W3 Total Cache keep entire pages in cache and as pages can contain comments, that user generated content is parsed for dynamic snippets as well.
WordPress core by default only allows a limited set of HTML in comments (“a blockquote code em strong ul ol li”), but it also leaves HTML comments in place.
As a result, blogs with WP Super Cache (before version 1.3) and W3 Total Cache (before version 0.9.2.9) were at risk of PHP code injection. Blog comments could contain dynamic snippets (in HTML-comments) and WordPress core did not them filter out. Upon a such a malicious comment having been submitted, a new cached version of the page was created that included the injected PHP-code. Upon the first request of the cached page, that code was successfully executed.
I stumbled on the vulnerability report about a week and a half ago, while researching why dynamic snippets weren’t executing when Autoptimize was active (simple really, Autoptimize by default removes HTML comments, the upcoming 1.6.3 will leave mfunc/mclude in place). As this seemed like a pretty severe security hole and as there was no feedback from developers in the support thread, I created a small “stopgap plugin” to mitigate the threat on April 10th, mailed firstname.lastname@example.org and email@example.com and requested WP Safer Cache being published on wordpress.org on the 11th. A couple of hours later WP Super Cache’s Donncha O Caoimh contacted me and the same day he released a version (1.3) that fixed this vulnerability by parsing out potential exploits from comments as they are posted and as they are rendered. On April 12th W3 Total Cache’s Frederick Townes confirmed they were working on a fix. Version 0.9.2.9 got released on April 17th, disabling dynamic snippets by default and when these are enabled, they require a secret alphanumeric key to be included in the snippet which is checked against one that is defined in wp-config.php.
Conclusions; The fact that this didn’t generate any fuss (as opposed to W3 Total Cache’s widely published information disclosure vulnerability in December 2012) is surprising. PHP Code injection clearly is a more severe security risk that must have been there for a long time already. The fact that this only got discovered recently is baffling. And why WordPress core doesn’t filter out HTML-comments from submitted blog comments, others seem to understand, but to me that remains the biggest mystery of all.