Security release of vm2.6.10 and vm2.9.9b

If you are using a version lower than 2.6.10, you should update right away.

During a routine audit done by the Sucuri firm, they found a critical vulnerability and informed the VirtueMart team.
The bug was immediately patched (in record time) and the version 2.6.10 (stable version) and 2.9.9b (in RC state) fixes this issue.

If you cannot update VirtueMart, please follow those instructions.

Our Security policy

There were recently some misconceptions about our security policy. Some people complain that we are not following the "Full Disclosure" philosophy (please read Full disclosure (computer security) ). The "Full Disclosure" comes from the beginning of the open source movement and is also to see as an answer to the "non-disclosure" behavior of proprietary software vendors. The experience was that sent vulnerabilities were not fixed. So the people learnt that revealing the vulnerability in public lead to a fast reaction of the blamed company. The evil guys of this business just started to blackmail companies.
There are of course also some other advantages. In case of Linux kernels, the idea is that all together work on a fix for it. The leaks are often a lot complexer and so the more people know about the faster it is fixed. Furthermore anyone should be able to learn from the leak to prevent the issue in future.

In our case, the most security leaks are fixed within minutes, maybe within 1-2 hours. So the argument, the more people the faster a fix is ready is not suitable for joomla/extensions. So we are following the philosophy of the "responsible disclosure" (please read Responsible disclosure ). Also sucuri.net is following this idea. They are professionals and know how to handle a vulnerability for the best of all users. They informed us secretly about the problem. We fixed it within a day, they tested our fix and asked if it is the right time to inform their customers. We did the most important thing, to provide a fix, only missing was the "responsible disclosure". So I agreed, but misunderstood them, because I did not meant that they disclosure the vulnerability in detail. A correct disclosure in our environment (php, opensource) must also always contain an explanation to fix the issue manually. The other reason is that the problem is actually in the joomla user "model" , and it should be also fixed in the JUser to prevent misuse of it before we should do the "Full disclosure". Persuading the joomla developers to protect their model got complexer than thought. Their argument is that there is no problem as long as you are using the Joomla Form. We got just stuck and must now prepare an explanation, why it is always bad to allow any form to override internal variables of an object.

How to get the security fix without updating VirtueMart

If you cannot update VirtueMart, there are two possibilites:

Exchange the file models/user.php

The easiest way is just to exchange the user model with the new one:

1. Dowload the latest version (VirtueMart 2.6.10 or VirtueMart 2.9.9b)
2. Replace the file /administrator/components/com_virtuemart/models/user.php with the new one.

The user model is almost untouched for a year, so you should first try just to exchange the model.

Patch the user.php file

If you think your user model is too heavily modified, it is enough to add a unset($data['isRoot']); to the top of the user store function:

1. Go to /administrator/components/com_virtuemart/models/user.php
2. Search for the function named function store(&$data,$checkToken = TRUE)
3. Replace if (!$user->bind($data)) { with

   if(!$user->authorise('core.admin','com_virtuemart')){
   	$whiteDataToBind = array();
   	$whiteDataToBind['name'] = $data['name'];
   	$whiteDataToBind['username'] = $data['username'];
   	$whiteDataToBind['email'] = $data['email'];
   	if(isset($data['password'])) $whiteDataToBind['password'] = $data['password'];
   	if(isset($data['password2'])) $whiteDataToBind['password2'] = $data['password2'];
   	} else {
   		$whiteDataToBind = $data;
   	}
   // Bind Joomla userdata
   if (!$user->bind($whiteDataToBind)) {
   		.....
   

We just creating a new array and setting any variable manually (white list).

The real problem behind all this

The JUser model bind function just loops through the properties of the class and sets data with the same name to the object. The filtering is done by an attached JForm (Gui elements) to filter the input of the data. So if developers use the joomla model without form, they have to filter the data themself, else it is possible to override internal variables of the object.
The binding for normal JTables does not override internal variables as long you follow the habit/convention to name them with a trailing underscore _. The check function additionally ensures that the data is correct. But the juser object does not follow the own joomla habits. Additionally it is very unclean to use MVC and to have a model, which needs GUI elements to do correct filtering. There exists enough tasks to use a model without any GUI. For a developer just using the joomla API it is like a trap. A model should be secure by itself, without the need of a "View" or "Controller" to be safe. SCNR, but joomla 2.5.16 fixed a security leak in some the JFormFields. So other solutions based on that were also very unsecure for years.

The suggested fix in the joomla user model is very easy. Just unset the sensitive data, if a user is not admin. This should be done in the bind function and in the store function. The advantage lays on the hand.
A lot other extensions for joomla become more secure. It is very unlikely that only VM has this problem.
People can do a small joomla update and still use their modified extensions.

Personally I see the request for full disclosure as a typical academic, but noobish request. Not only the good guys learn from disclosures. The black hat fraction also learns from it. It is important to differ and sometimes a full disclosure makes absolut sense, but not always. It depends on the complexity of the problem, how many people already know about, the reaction of the maintainers, and so on.