The release notes for 220.127.116.11 state that “Several potential security vulnerabilities” were fixed.
1) Since which version did these vulnerabilities exist?
2) What exactly did they cause?
3) How can I secure my websites if I cannot update to that version?
Like any coding framework, your going to find potential vulnerabilities. So they aren’t going to publicly announce the issues (though since its open source you could figure it out on your own). The only way to secure your website is really to upgrade. Magento was made to upgrade and like most other software you need to upgrade to stay current with the security patches/new features.
all open source projects I know are dealing with security issues in such ways that details are published once a bugfix is available (or even earlier). They also state which versions are affected, if there is a workaround or maybe a patch.
We have multiple installations for customers that we cannot easily update, as this certainly would break themes, etc. I have some experience with updating Magento installations and afair there was no installation that didn´t have problems after the update. Sad but true, updating Magento is a pain in the a**.
So, if Varien would provide more (or better: any) information, this would help users/security a lot.
I can’t speak to the policies or practices of providing or not providing vulnerabilities info - it may be an omission, it may be deliberate, I don’t know - but you have another issue about which you should be concerned:
We have multiple installations for customers that we cannot easily update
This really should not be the case. Magento’s theming and programming architecture allows for customization while preserving a clear upgrade path. I’d try and determine what prevents you from updating, as Magento both fixes security issues and advances/enhances the framework by incrementing versions. Patches levels work for the life of a minor version (the “x” in 1.x), but after the codebase advances to another minor version, the previous version should be considered EOL’ed. I assume that this approach is what has given the Magento framework its high development velocity.
That said, you have two options. Because all version source is open, you should be able to use the provided diffs (or create your own) and divine the vulnerabilities. If you and your clients are using Enterprise Edition, then you should be able to get further help from Magento Support.
<<Edit: The term is Responsible Disclosure>>
Although many open source projects are very public with their security vulnerabilities, they also don\’t have the same burden Magento does. Being a system that is almost guaranteed to involve peoples financial information as well as financial information for the company running the instance of Magento they can not afford to be completely public with the vulnerabilities until a time when they are sure the majority of customers have upgraded.
At the Imagine conference this year I attended an excellent session about security vulnerabilities in Magento where the speaker demonstrated how to seriously compromise an older system. The vulnerability had long been fixed, but if it was public (he did not show how it was done) ANY site that had not yet updated could be attacked. Given that, would you really want Magento to publish exactly what was fixed?
And I agree with Ben in that your sites should not be difficult to upgrade. I have yet to work with a system of this complexity that goes to such lengths to enable smooth upgrades. If you modified the core, that is on you, heh. Sorry. If everything was done using modules and standard rewrites etc than upgrading should be easy. Magento is a system that handles money. Surely they can afford to dedicate resources to upgrade.
I agree that this is an issue and I am concerned, but so far the updates from 1.2, 1.3 or 1.4 to 1.5 have been problematic in most cases. Even if you separate your own code into the “local” directories, you still have to adapt it on update. Also, using external themes and extensions these had problems.
I don´t know if this changed with the newer versions like 1.6, but till now it was rather complicated and time consuming to update a Magento installation. And while this might be a subjective impression, it seems like many people have these problems.
Compared to TYPO3 which we use a lot, the update there is much easier. For minor versions, you only have to change the symlink and in an instant, all websites use the new source. For major versions, you change the symlink to the new version and then there is an upgrade wizard guiding you through the necessary steps to complete the update. Sure enough, there also arise problems, but over all it´s normally a very easy task.
@Tim: While I understand the fact, that it is problematic to disclose specific details on security vulnerabilities, I wish there would be at least more information on which versions are vulnerable and to what extent.
You should also be aware, that “The Bad Guys (TM)” will check the differences between the Magento versions to find out where the vulnerability is. So, you really don´t win anything by keeping such information back. I also don´t think that script kiddies could use that information, so I can´t see anything positive there.
If you modified the core, that is on you, heh. Sorry. If everything was done using modules and standard rewrites etc than upgrading should be easy. Magento is a system that handles money. Surely they can afford to dedicate resources to upgrade.
Core either wasn´t modified or modified using modules. Many customers tend to not want to invest more money once the shop has been finished… =(
btw: Why do I have to enter the captcha every time I post? Shouldn´t this be one-time-only on registration? Rather annoying…
The 1.8MB diff is a _good thing_(tm) because if it was easy to find them then your previous post would be completely correct.
The reality is, a vulnerability can often be fixed with one little change. Seeing that change does not necessarily disclose what was vulnerable and how it can be exploited.
$var = $_POST[’myparam’]
$var = $request->getParam(’myparam’)
is a change of minor consequence at first glance. But that var may later go on to be used in front-end code and expose the system to XSS attacks. Where and how aren’t apparent from that line. But, if you posted in the change log
“Fixed XSS vulnerability from unchecked parameters passed in from users”
The ‘bad guys’ will know pretty quickly what is up.
The major security vulnerabilities are like this. Things not being checked. The nature of this really is “Security through Obscurity” which is no real security at all. But it’s all we have when we open-source code. We have to deal with that.
It may be worth a chuckle for you that I tweeted this not too long ago:
Because you are in part correct. If you are dedicated enough you can find the vulnerabilities.
That being said, you should assume all versions are vulnerable in most cases, unless the patch comes immediately after another patch. This happened once with Magento in my memory. A release came out that exposed a way to put files on the server and they patched it immediately. In that case only the newest version was vulnerable. If it isn’t that, just assume all versions to be safe.
I know 1.2-1.4 can be tricky at times to update they really need to do it. That may not be the answer you want, but it has to happen. Things get better with higher version numbers. As far as commercial templates, not sure what to say. I have also had problems in the past. My company builds custom templates for our clients and we strive to do them in a forward-compatible way. When they aren’t, we are there to update. Same goes with Wordpress, Joomla, really any other non-PHP software (Websphere Commerce you need to start over every major update. Blah)
1.8 MB diff: But as it is not easy to find in there, do you think a normal consumer/admin wants to search for it? I guess attackers have got more time and more experience to search for vulnerabilities.
I agree with you that old installations need to be updated. Really, I would rather start yesterday than wait for our customers. Though, the problem is that we cannot (from an economic point of view) update each and every installation and then spend time to fix alle issues that might arise. Therefore, we have to make an offer to our customers (that sadly some “can” decline ).
Interestingly enough, Varien just published a major security concern along with patch files for versions down to 1.4 and a workaround for cases where this patch cannot be applied:
Thanks! That´s the way I like it and almost all our installations have been updated with that patch already =)1.8 MB diff: But as it is not easy to find in there, do you think a normal consumer/admin wants to search for it? I guess attackers have got more time and more experience to search for vulnerabilities.
I agree with you that old installations need to be updated. Really, I would rather start yesterday than wait for our customers. Though, the problem is that we cannot (from an economic point of view) update each and every installation and then spend time to fix alle issues that might arise. Therefore, we have to make an offer to our customers (that sadly some
as the one who found the issues fixed in 18.104.22.168 I can tell you:
- As an attacker, with an little knowledge of hacking web-based software, it might take an hour to find the issues by reading the diff-file if you search for them and now Magento quite good.
- The issues aren’t as critical as the new Zend_Xmlrpc issue.
- For your, and your shop’s security, it is most of the time more important to not reveal the complete information about the issues.
See, Magento is an ecommerce platform, not a little board-software for the local cat-lovers. Each Magento installation deals with big amounts of money.
An attacker who finds out the security issues by reading the diff-file and knowing Magento well enough to get them is also able to figure it out by himself without the diff-files. But an attacker without knowledge of Magento will be blocked by not releasing every detail. And that’s the way Magento goes.
“At the Imagine conference this year I attended an excellent session about security vulnerabilities in Magento where the speaker demonstrated how to seriously compromise an older system.”