The vBulletin team just issued a warning, and released patches for a security exploit that affected all versions of vBulletin including 3.5, 3.6, 3.7, 3.8, 4.X, 5.X. They recommend that anyone using vBulletin apply these patches as soon as possible. Here is part of their announcement:
A security issue has been found that affects all versions of vBulletin including 3.x, 4.x and 5.x. We have released security patches to account for this vulnerability. This includes patches for vBulletin 3.8.7, vBulletin 4.2.2 and all versions of vBulletin 5 (including Cloud accounts). The patch is also applied to vBulletin 5.1.0 RC1. It is imperative that you apply these patches as soon as possible.
Due to functionality changes, the minimum PHP version for the patch is 5.2.0. This represents an increase for vBulletin 3. Alternatively customers can install the JSON functions separately in which case it will work with any compatible PHP version that their particular version of vBulletin supports. You will need to collaborate with your hosting provider or systems administrator to apply the changes to PHP.
If you are using vBulletin, you know what to do: Patch now!
What really worries me from this announcement is that they increased their minimal PHP version requirement on the security patch. It means many webmasters will not be able to apply the patch quickly enough, and some may end up breaking their sites.
So, if your host is not running an updated version of PHP, you need to contact them ASAP to get it updated or your site will be vulnerable.
What a Security Exploit Means?
The vBulletin team provided no details on what exactly they patched, or what the vulnerability was. All they have said is it was a “security exploit”, which should be enough of a warning for people to update their forums.
Based on their patches, we were able to clearly see what the issue was.
They removed:
$temp = unserialize($check);
And added:
$temp = json_decode($check, true);
Later in the code where they were running serialize($_POST, they changed it to json_encode($_POST). It appears like a PHP Object injection where they are passing user-supplied data to an unserialize function.
This may lead to privilege escalation, remote code execution, or maybe even allow an attacker to run any PHP function they want. We don’t know how bad it is yet, but our team is still investigating this issue and trying to confirm the severity and what can really be done.
Users running our Website Firewall are already protected against PHP Object injections, and we are building a custom virtual patching signature for it as well. Stay tuned for updates.
So nobody knows what the potential issue with this exploit is and everyone is jumping on the RCE boat as usual. Security experts scratching there heads hmmm.
I’ve yet to see any kind of POC of this apparent exploit, looks to me vB finally got off there ass and realised they unserialized user input and just issued a patch incase there was a security rick. The only magic function you can inject with the object injection is __destruct which unlinks a file.
Unlinking a file = deleting a file.
So you might be able to delete any file on the underlying file system (as long as your www data user has the rights to…)
in fact, it can’t delete any file even. Because the __wakeup function will make the filename to NULL.