Magento is not the first project to face this issue, so reading a few of the results from a google search for security through obscurity open source should be helpful as we discuss how to proceed.
I don’t consider this situation to be “security through obscurity”. If it were “security thorough obscurity” then the Magento team would have seen an exploit and not done anything about it because they thought no one new of the flaw or was unlikely for someone to find it. In the case of this recent update they have fixed the exploit and did not just let it go.
The problem is that they claim that for someone’s protection they don’t intend to release information. That is “Security though obscurity” by definition. Even Microsoft gives more details in their hot fixes (please don’t hate me for that comparison).
If you check out fedora or ubuntu update release notes, that is how I think it should be done.
I would really love to get someone from the Varien team on here so we can discuss with their perspective. I don’t want to bash them, I just want for everyone to come to an understanding, even if its me understanding why they won’t release the information.
they have fixed the exploit and did not just let it go.
What’s lacking in this situation is the opportunity for efficient peer review. In the blog post I’ve already posted one way this patch may have been incorrectly applied. None of us are perfect (hence the existence of bugs in the first place) and security fixes are the most important area we should seek others input.
Frankly, I haven’t even adopted Magento yet and can’t really dedicate my entire day to looking into this security update. However, the two hours I’ve spent so far (sheesh, plus an hour typing into forums and blogs) could have been spent much more effectively if I hadn’t spent most of that time reverse engineering the security update. I first heard of Magento yesterday, so it’s also slow going just figuring out how it works.
A cracker (black-hat hacker) who already had their eye on Magento would be able to work much faster than me. They’d already be done reverse engineering the security update and implementing any exploits gained from that effort. The bad guys don’t wait for “more details” before getting to work. Once they smell blood in the water, they get to work. We beat them by having more good guys working on the problem.
All the security benefits of an open source project are moot if it doesn’t implement peer review in an efficient way.
I could see that as a good compromise maybe. Sorta like what happened with the DNS issue last month or so. They didn’t release any information about the hole until they (the big players ie Microsoft, the BIND folks, etc) thought it was mostly fixed.
We do need to find a balance between people who just want to use vanilla copies of Magento and people who really customize it. I don’t apply any updates to our servers until I know exactly what the updates change. But that is because I understand what is happening under the hood. Most people would be best served to just keep their systems up to date no questions asked.
Once we go live with our site it has to be up 100% no matter what. I won’t be able to afford to play around with updates and security. That is why I keep several virtual machines running all of our production systems so I can play with them. I probably will start doing this with our beta site soon, I just hate having to keep updating all the copies during the development phase of a project.
I’m in the same boat as Lee Saferite who posted to the blog. I can’t tell my boss “oh they said they fixed whatever it was.”
I’m accountable for the security of any software my websites run whether I code it from scratch or use an open source program.
Just to be completely clear, I wouldn’t care so much if Magento wasn’t already an amazingly great piece of software. I was sold on it yesterday and I had fully planned on devoting many of the hours I would have spent programming my own ecommerce store into contributing to Magento. I still plan to do that, but it’ll be frustrating if I have to do duplicate work. I’m adopting Magento to avoid duplicate work.
The reason why they do not disclose fixed vulnerabilities is because they don’t want people using previous versions to be exploited. Let me shed some light on this. Any attacker that’s skilled enough to exploit a bug in Magento—unless we’re talking of the unlikely possibility of something as trivial as an SQL injection or XSS—will be able to make a diff of the patch and find what was implemented and how to exploit unpatched sites. Therefore the only persons who are penalized by Magento’s security by obscurity are their own community developers. People who, like me, will not upgrade until we have a file change list or at least an explanation of what was vulnerable and how it was fixed.
Each of us developers could easily generate unofficial release notes to share with the community. Out of respect for Magento, it hasn’t been done (at least not thoroughly and publicly). We can also generate a diff list - we just chose not to waste our time doing Varien’s job, mostly out of respect.
As for 1.1.4, I have upgraded. I have generated my own private diff list, I have figured out what files needed to be changed to fix the vulnerability and I have applied a selective patch myself.
I personally think a list of changed files would be nice to have with each release, especially if there are changes to the templates. However, the information is not exactly hidden. Just run a diff on any of the various folders in /downloader/pearlib/download/ and you’ll get a list. I personally use DiffMerge http://www.sourcegear.com/diffmerge/.
It took me literally 10 seconds to figure out what was changed in 1.1.4. Now, understanding those changes and their purpose is a completely different thing.
I can’t believe I’m actually going to say this, but I actually prefer the way osCommerce handles this. Now to be fair, the way osCommerce does it is out of necessity, because it’s not possible to upgrade osCommerce unless you’ve left it almost 100% stock. What they do is include an update document with each download that lists all of the fixes in that release, then under each issue it gives you a list of files affected and exactly what to add/remove/change in order to apply the fix. That way you can see exactly what was changed for each fix and if it’s going to interfere with any of your own changes.
When I saw the update I told my boss that there was an “imporant security update” for magento. He promptly asked “what did it fix?"… To sum up the converstion, the fact that there was an “unknown” secruty hole in the version we where using was a big deal, causing a decision to push back our release date. Just like WhoIsGregg:
I can’t tell my boss “oh they said they fixed whatever it was.”
I do think a list of fixes is right and proper. I don’t install Microsoft patches unless I am sure that the patch is required.
Whilst I understand the need to keep mum regarding possible vulnerabilities lets not forget that any worthwhile web master should patch any critical issues as soon as they arise (and are notified that a fix is available).
If a site is unpatched after a fix is released then it is the fault of the site admin.
Full disclosure would be good, I am sure the people interested in exploiting magento will have significant resources to discover what has changed - and really if they did a good enough job then the hole should be plugged and (as stated before) the site admin should be responsible for applying the fix.
My annoyance with these “upgrades” is that they quite often replace files that were not even changed, an example being Catalog/Model/Convert/Adapter/Product.php was replaced with this last “patch” I had hacked this file to allow a gallery of images to be imported (among some other things) and after applying the patch my changes were gone like the wind (I do have my own patch set so they were not permanently lost) I think the “Downloader” should be able to generate a report of files that will be changed BEFORE changing them, that way I do not have to guess if a template has been modified or something else.
In summary : A company that is not transparent with its changes is not (what I consider) an open source company.