Security Risk: High
Exploitation Level: Easy/Remote
Vulnerability: Access control bypass / Increase of Privilege
Patched Version: 2.6.10c
If you’re using the popular VirtueMart Joomla! extension (more than 3,500,000 downloads), you should update right away. During a routine audit for our Website Firewall (WAF) product we found a critical vulnerability that could be used by a malicious user to easily gain Super-Admin privileges on your website. With super-admin access, the attacker has full control of the site and database.
The bug was discovered and disclosed last week and immediately patched by the VirtueMart team (in record time). They also released the update 2.6.8c to fix this issue.
What Are the Risks?
Any Joomla! based website running the VirtueMart version <2.6.8c and allowing user registration (default mode for VirtueMart – since it is an online shopping cart for Joomla!), are at risk of a total website takeover. A successful exploit would allow an attacker to become a Super-Administrator and do anything they want, this could include uploading backdoors to your server, running spam campaigns, or distributing malware to your visitors.
If you use an affected version of this extension, please update it as soon as possible! Note that sites using our WAF (Website firewall) product are already protected against this threat.
Technical Details
Update: We are removing the technical details as requested. Other extensions might be vulnerable to the same issue, so we will do more research on that.
VirtueMart uses Joomla’s JUser class “bind” and “save” methods to handle user accounts information. That’s not a problem in it of itself, but this class is very tricky and easy to make mistakes with.
The bind method roughly does the same thing as PHP’s array_merge function, except for a few points such as live password encryption and the fact that it operates on a class rather than an array.
In the above code snippet, you can see that the extension pass the $data variable (which, at this point in execution, contains the whole $_POST array) directly to the bind() call. While it is an effective way to save/modify user informations, not whitelisting what parameters should be modified is a very bad idea. It basically allows anybody to modify every single variables within JUser’s class scope!
Using this dangerous behaviour, an attacker could modify JUser’s $isRoot, $groups and $_authGroups variables to add their account to the Super-Administrator group, thus giving them full privileges over the target website / environment.
Upgrade VirtueMart as Soon as Possible!
This is a serious vulnerability and the VirtueMart team did their part by releasing a patch right away. Now do your part and update any site using it.
Great post, but can you perhaps nudge us a bit toward the location of the security risk. We currently have some projects in 2.6.8 which cannot be updated easily. We have to fix this by hand (line by line). Thanks in advance! m/
Hi, I have the same problem as Martijn, can you please give us some list of updated VM core files? Thanks.
The news informing about the security release is here, as well as the fix for those who cannot update VirtueMart
http://virtuemart.net/news/latest-news/462-security-release-of-vm2-6-10-and-vm2-9-9b#fix
I am astonished how many people let them be fooled by statements of a very inexperienced developer. The Joomla! Class works actually exactly as it should. It’s a (sort of) model class and model is usually not meant to validate user input.
Let me put that straight, Virtuemart is passing the entire POST array, unfiltered, to a model class and then storing the data into the database.
This is a very amateurish behavior for a developer and show lack of understanding of the basics of MVC.
Long story short, this is not Joomla! fault and I doubt you will find many (if any) other extensions affected by this so called “bug”
Joomla is only good at controlling but it does not take any responsibility. It currently run like the american government.
I am not a Vm fan.. Obviosuly VM made a mistake and they’ve should’nt blamed but Joomla has mistake in that respect as well.
it’s like—
FedEx (joomla) is available around the world… if i go to one of it’s branches in Cali (3rd party developer) and send a package.. However one of the agents in that branch stole my package…
So Fedex is not liable for the loss of my documents but the agent who stole it?!?
Thankfully FedEx take good care of their community and make sure everything is done right and then give it’s full responsibility.
Why not Joomla filters the ins and outs? so extensions like Vm which is done by an amateur developer cannot run in situation like this? And this way the Joomla community is protected. There are a thousand of extensions out there…impossible to check each individually… just saying…….
Everything right, except that we are not amateurs. No one wonders that VM had several audits and this was not found in years? Seems not so easy as people all the time tell. The reason are the misunderstandings and wrong informations flying around http://virtuemart.net/news/blog/463-reply-to-radeks-coffe-159
More infos are here: http://virtuemart.net/news/latest-news/462-security-release-of-vm2-6-10-and-vm2-9-9b
The news about the security relase is here: http://virtuemart.net/news/latest-news/462-security-release-of-vm2-6-10-and-vm2-9-9b
as well as the fix for those who cannot update VirtueMart
Here is patch info etc http://virtuemart.net/news/latest-news/462-security-release-of-vm2-6-10-and-vm2-9-9b
Sorry but this patch is not a patch at all. It just unsets one single variable from the passed post data. It is still possible to write an SQL injection and/or modify other data within this particular table. At least this is what I can say from a quick look at the code provided in the news
Just curious – (question from a non-programmer) since the same piece of code is part of Joomla 1.x , does that mean all old Joomla 1.5 sites share the same problem?
The “problem” has nothing to do with Joomla.
As Dan wrote before, this is not an issue with Joomla! but solely with VirtueMart. The JUser class was always working that way and this is how this class supposed to work. Every decent developer know how it works and know that (s)he has to validate the user input before passing data to the “bind” method.
Can I ask if it is just one version of vm that’s affected – ie if none of my sites are on 2.6.8 am I ok or is this any vm 2 site pre 2.6.8 or is this also vm 1 sites for joomla 1.5?
Thanks jodee