Things have however taken a turn for the worse now; I’m not only getting logged out from Facebook on my 3 devices (work Win XP PC, home Ubuntu netbook & Android smartphone), I’m now even getting locked out of my account altogether, having to change my password on my smartphone (as that one has the OTP generator in the Facebook app). This happened 4 times in the last week and it is that frustrating that I disabled Facebook Chat in Thunderbird. And maybe that’s just what Facebook is aiming for; encouraging users to use Facebook Chat in a Facebook-owned/ -controlled context instead of in a neutral, ad-free 3rd party application? Wankers!

Watch this video on YouTube or on Easy Youtube.

Watch this video on YouTube or on Easy Youtube.

There is, however, one security-related shortcoming in WordPress from a design point of view: sessions are not stored server-side. If someone logs in, a cookie is set in the browser containing username, a session expiration timestamp and a hash. With every new request to WordPress that cookie (and specifically the hash) is checked to validate the session, but there is no check to see if there indeed was such a session.

This can be considered mainly a theoretical shortcoming, not an immediately exploitable vulnerability, because;

1. session-cookies are set with the HTTPOnly-flag so XSS should not be an issue
2. in an ideal world all traffic, once logged in, would be over HTTPS, securing against network sniffing.

But there are other (albeit less obvious) ways to steal cookies or even create create new ones to gain unauthorized access, as demonstrated in this very detailed blogpost. As explained in that article, there is no way to block “fake” session-cookies from gaining access (your OTP plugin won’t protect you either) and there is no functionality to monitor and if needed delete sessions.

So … I wrote a small proof-of-concept plugin that gets triggered upon login, logout and upon session verification (i.e. each request) and which stores sessions server-side, automatically logging out unknown sessions. With that in place, lots of other optional features could easily be added;

• display a list of all known current sessions
• allow one or more sessions to be removed
• compare IP address at session verification against the one at session creation and notify or logout if no match
• compare User Agent (and optionally some HTTP accept-headers) at session verification against the one at session creation and notify or logout if no match
• create an audit log
• …

But … I don’t want to do this on my own. I have 3 plugins already, 2 of which are semi-popular and for which I try to do regular releases and provide great support (and I have a daytime-job and a wife and daughter with whom I love to spend quality time as well). Moreover I really don’t want the plugin to “just” be open source, but I want it to be developed in an open source, collaborative manner as well.

So if you’re a WordPress coder, a security consultant or just an innocent passer-by and you are willing to code, review code, translate or document, then do drop me a line. Fame (but not fortune) will be yours!

Watch this video on YouTube or on Easy Youtube.

The vocals are by the Michael Smith, who apparently was only 12 years old when recording “Manila”. There’s multiple remixes of it (and the official clip for the Ewan Pearson remix is pretty funny), but none are as wild as this one. Love those crazy horns, they remind me of (the more recent) Neneh Cherry & The Thing with their freaky cover of Springsteen’s “Dream Baby Dream” (which Four Tet remixed as well).

Maar “nee!”, de (Katholieke) Kerk heeft al lang geen monopolie meer op de grote levensmomenten. Want “ja!”, er zijn alternatieven; zeker voor ongelovigen. Het hangt er gewoon van af wat je er zelf van wilt maken, hoe je die grote momenten wilt vieren. Veerle en ik zijn diep-ongelovig en hebben in 2002, samen met een toffe madam van wat toen nog de Unie van Vrijzinnige Verenigingen heette, zelf onze trouwceremonie uitgewerkt. Met diezelfde vrouw hebben we in juli 2006 de geboorte van onze dochter op een voor ons zinvolle manier gevierd. En Elise heeft net haar Lentefeest achter de rug.

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?

Dat zelfstandig denken, we gaan dat ongetwijfeld nog vervloeken, maar het is een lief, slim en grappig prachtkind, ons Elise. Ze mag nu stoppen met groot worden, het is goed zo!

Watch this video on YouTube or on Easy Youtube.

The problem was in the interpretation of dynamic 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.

The vulnerability, which was originally discovered by kisscsaby and reported 3 weeks ago on the wordpress.org plugins support forum, had multiple causes:

1. 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.
2. 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.
3. 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 security@wordpress.org and plugins@wordpress.org 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.

Watch this video on YouTube or on Easy Youtube.

Beautiful, no?