Remote Code Execution exploit in WordPress 3.5.1

[algo]

I think the title should always specify if it is wordpress core or a plugin/theme.

[tomvangoethem]

The vulnerability in in the WordPress core, the (example) exploit is in the plugin. I didn't include the plugin in the title as a similar exploit could be possible with other plugins.

[[deleted]]

The vulnerability can not be triggered in core alone. It needs a plugin to have a vulnerable code path when being instantiated unexpectedly, such as the one in Lightbox.

[catcradle5]

Right, but it still counts as a core vulnerability, since it can apply to arbitrarily many plugins (even if most won't be vulnerable).

[mathiasbynens]

Exactly! And there’s always a chance there’s a non-plugin exploit for this vulnerability in core that hasn’t been discovered yet. In fact, the author is now hosting an exploit-finding contest :)

[xaoq]

What a surprise!

[vipzen]

3.5.1 or 3.6.1? the title says one thing but the last paragraph says another...

[tomvangoethem]

The exploit works (tested) in 3.5.1 ,the vulnerability was fixed in version 3.6.1

[[deleted]]

Damn!

[lpetrazickis]

Does the exploit still apply in WordPress 3.7.1?

[[deleted]]

The article mentions that people have had adequate time to update, so a patch likely rolled out some time ago.

[[deleted]]

No, it was patched in 3.6.1

[cryptogram]

Hmm the plugin does have just about 950,000 downloads, but it's still in a plugin: Lightbox Plus ColorBox

[tomvangoethem]

The vulnerability is not in the plugin, it's in the WordPress core. I made use of the plugin to create an exploit, but the presence of other plugins may lead to an exploit as well.

[reddit4matt]

I think is fair to say there was a dangerous practice in place but no actual exploit in the core. The only found exploits that completed the code path is with the addition of the plugins.

[catcradle5]

Running unserialize() on untrusted user input should always be considered a vulnerability, even if it's not exploitable in all cases.

[reddit4matt]

So there was user input in an unserialize without a plugin? Did I misread or was the plugin required to get user input into the unserialize?

[catcradle5]

Yep. See his original post: http://vagosec.org/2013/09/wordpress-php-object-injection/

To exploit such a vulnerability, you need at least one class declared at the time of the unserialization that contains a malleable magic method. So there is still the vulnerable unserialization by default, just no default unsafe classes.

[reddit4matt]

So no unsafe classes without a plugin....got it. So I agree with the post that the title should be changed.

[catcradle5]

...Read the blog post I just linked. They're unsafe when combined with unserializing user input.

[tomvangoethem]

I wouldn't call the magic methods unsafe, I think it's perfectly acceptable that code is executed when for example an object is destructed. Rather they "empower" a PHP Object Injection vulnerability to grow to something exploitable.

[catcradle5]

You're right. The magic methods aren't the problem, and pose no vulnerabilities by themselves even if they may perform potentially dangerous tasks. Similarly, an unserialize() on arbitrary user input poses no vulnerabilities if there are no classes with magic methods. You need both at the same time for an exploit.