Sophos Cloud Optix
Mega-popular blogging and content management system WordPress has just put out version 3.6.1.
Since it’s a maintenance release (an update from 3.6), it doesn’t have a huge raft of new features, but it does fix three security holes.
One of them is a Remote Code Execution vulnerability reported by a young Belgian web application security researcher named Tom Van Goethem.
Now that the fix is out, Van Goethem has published a very detailed description of the bug and the steps he went through to uncover it.
He also mentions that, by using a popular plugin, he was able to go from vulnerability (“there’s a hole, and it could be risky”) to exploit (“here’s how to use the vulnerability for unauthorised access”).
Fortunately, however, he hasn’t gone down the complete-and-total disclosure route, stopping short of giving you a working exploit and, saying:
Due to ethical considerations, I will not disclose a Proof of Concept of this exploit at this time, as there are too many vulnerable WordPress installations out there.
Van Goethem’s bug relates to PHP serialisation.
That’s where you take data, and perhaps even code, from a programming environment, and convert it into text string representation.
This means it can easily be saved, moved around on a network, and restored later.
It’s called serialisation because even data structures that have a complex layout in memory, such as arrays and tables, end up as a linear (i.e. serial) stream of bytes.
Going back from a serialised text string to live, run-time data inside a program is, unsurpisingly, known as unserialisation.
Any software that inadvertently passes unfiltered, remotely-supplied data into an unserialisation function is taking a bit of a chance, and that’s what was happening inside WordPress.
By the time you get round to validating that unserialised data, it already exists as a live data structure inside a live run-time environment: that’s a bit like dry-firing a handgun as a way of satisfying yourself that it isn’t loaded.
WordPress, which currently claims more than 7.5 million downloads, has unsurprisingly suggested that “you update your sites immediately.”
Note. Sophos Naked Security and the Sophos Corporate Blog are hosted on WordPress.com VIP servers. These servers were already updated by the time we received the advisory email from WordPress [2013-09-12T13:24Z].
I usually see the term "deserialization" rather than "unserialization", though my browser doesn't like the spelling of either of those. Anyway, the point is programmers should always check data coming in to make sure it's legitimate, even if they think the source of the data is something else they control.
The PHP names for the save-to-string and restore-from-string functions (and thus the names used in the linked-to paper) are "serialize()" and "unserialize()".
So I took the "un-" prefix, rather than "de-", and adapted it to my own preferred orthography, using "-ise" suffixes rather than "-ize."
The recommended way to do {ude,de}seriali{s,z}ation in PHP, from what I can see, is to use "json_decode()" instead.
JSON is a simple, easy-to-parse, seralised encoding that doesn't let you magically instantiate PHP class objects in one shot, so it ought to be safer.
Oh, and your "even if they think it's OK" remark is MOST important! I was going to say "especially," not just "even," though that might have overstated the case…but if input data is worth checking, it is worth checking all the time 🙂
"reported b a young Belgian web application security researcher" *by
Fixed. Thanks 🙂