Magento eCommerce PHP Remote Code Execution
ma.ttias.be
ma.ttias.be
Arguably it's been years since I worked with it, but installation was weird, developing is slow a cumbersome, documentation was lacking, search was pretty much broken and it was slow. I can't image running it on a shared host, performance must be terrible.
On the positive side Magento does have an impressive amount of features.
I also asked them to clarify the versioning scheme[1] specifically related to patches, etc. It sounds like it should be better, but it's hard to tell at this early stage.
They've also taken a radically different approach to documentation with Magento 2. [2]
If you wanted to call them out, at least call them out for something which actually runs during normal operation.
Every book I've ever seen on Magento seems to think the same. That 777 permissions are just not a big deal.
"All directories have 700 permissions (drwx------). 700 permissions give full control (that is, read/write/execute) to the owner and no permissions to anyone else.
"All files have 600 permissions (-rw-------)."
Granted, the tool I used is opinionated and not all those items are red flags, but the sheer number of issues is impressive.
Plug: Had to write a full page caching mechanism that's powered by Varnish (dubbed Magento Warp - http://www.unixy.net/varnish/ ).
We had 3 cache servers with 128GB of ram EACH just to cache the complete shit out of Magento pages. Each user had their own keyspace in the cache. _that's_ how bad Magento is.
When cache would go down because of a network partition or something, Magento would fallback to rendering and our application web servers would melt.
Fwiw we partial view cache on our platform and achieve a 90%+ hit rate on most sites. Some run many user-variable-specific (referrer,cookie,stored data) site versions which drops the cache hit rate, but is worth the extra cpu and cost for the conversions. Little performance hit as the object data to render is already in memcached usually, pre-warmed by queued parallel processes.
Of course, we evolved this in response to "oh crap the web tier is burning", but I just can't comprehend how magento haven't come up with something better than what you describe. Perhaps they haven't experienced the pain of clients bearing down hard on you while Rome burns first hand, and don't understand the importance.
Those flat tables really don't help much... (just profile the a request made to them and you still see the insanity that kcachegrind can generate).
They also didn't think about stores that have a lot of attributes. We had over 650. That means we had MySQL tables with 650+ columns.
Then there are SKUs. We had hundreds of thousands. Now there are HUGE tables with LOTS of columns that needs to be indexed on a regular basis because products and more attributes are being added. Reindexing takes hours.
Magento is a mess and that's all I have to say about it.
It's trash. We spent more time trying to get a theme to load properly than we did actually working on the theme.
That being said, it's getting old, and it shows. They have built up as much as they could, and right now we have a tower that might drop at anytime.
Magento 2 will solve this.
Magento is a monolith and always will be. It's built on top of PHP's slowest framework, Zend which doesn't advertise speed but rather raw power.
Magento is going to crumble, it's just a matter of when
Regarding the crumbling comment... well, Magento is seven years old. There's a reason we're releasing Magento 2. Code's on GitHub, PRs welcome: http://github.com/magento/magento2/
If I got paid every time someone ditched magento because it doesn't perform, is hard and costly to host/maintain, gets blind alley'd by "someone else's problem" developers, can't do what they need, I'd be a rich man.
Oh wait, I do, and I am.
> Magento is a piece of junk
Commerce is hard. Making an extensible commerce platform for all/most merchants is even harder. These two reasons are why there aren't a lot of options in the open source PHP-based eCommerce application space. Redesign (Magento 2) will be released in Q4 of this year (2015). Beta code is available on GitHub and we are accepting PRs: https://github.com/magento/magento2/
> installation was weird
How was installation "weird" when you were using it?
> developing is slow a cumbersome
Speed of development depends on knowledge of architectural conventions, not unlike getting started with Symfony, Zend, Laravel, etc.
> documentation was lacking
I started building Magento projects in 2008. Documentation was non-existent for a long time (unfortunate given the esotericism of the app). We're solving this for Magento 2 by having tech writers on staff and by soliciting community help (docs are also on GitHub, PRs accepted): https://github.com/magento/devdocs
> search was pretty much broken and it was slow
Search and newsletters are insufficient for anything but the most basic needs. That's why there are so many SaaS search vendors filling this space quite well via free extensions.
> on a shared host, performance must be terrible
Shared hosts are never appropriate for commerce sites due to security reasons. There are a number of specialized small business hosts which run < $50 / month. For shops lacking that budget, well, there will be challenges in general.
Magento has just started posting notifications of these vulnerabilities in their notification center. They sent two messages. One on April 16 and another on April 19. See images of message here http://imgur.com/a/edVGy they did inform us that a press release with the vulnerability was coming.
That said I am annoyed that the patch was from February 2015 and October 2014. If you do not go to this page https://www.magentocommerce.com/products/downloads/magento/ on a regular basis there is no way that I know of to get same day notification of new patches.
Btw, see the comments section in Mattias' blog post, you will see that Magento themselves admitted that they have "no automated tests" whatsoever. And 2+ months out, they haven't bother to updated the latest code release with the new patch in.
Do you still trust Magento stores on the Internet? I don't.
Personally I've never liked Magento much; it needs expensive hosting even for modest shops and seems to be bloated with functionality you never use. And in the end you always end up with writing a bunch of custom modules because the Magento way is never your way.
Because Magento are OBSERVABLY INSANE.
This is from the Magento Enterprise tarball. I can't say how much we're paying, but I can say it's public knowledge that it's at least $13,000 a year:
$ grep -r chmod app | grep 777
app/code/local/Gorilla/Heartbeat/Helper/Data.php: chmod($logDir, 0777);
app/code/local/Gorilla/Heartbeat/Helper/Data.php: chmod($logFile, 0777);
app/code/core/Mage/Install/Model/Installer/Console.php: @chmod('var/cache', 0777);
app/code/core/Mage/Install/Model/Installer/Console.php: @chmod('var/session', 0777);
app/code/core/Mage/Install/Model/Installer/Config.php: chmod($this->_localConfigFile, 0777);
app/code/core/Mage/Compiler/Model/Process.php: @chmod($dir, 0777);
app/code/core/Mage/Catalog/Model/Product/Attribute/Backend/Media.php: $ioAdapter->chmod($this->_getConfig()->getTmpMediaPath($fileName), 0777);
app/Mage.php: chmod($logDir, 0777);
app/Mage.php: chmod($logFile, 0777);There don't seem to be any specific vulnerabilities related to these permissions, though I'd like to see them go away. It's my understanding that 777 will not exist in Magento 2.
As I said: Magento Enterprise tar ball, supplied at considerable expense straight from Magento. Magento bears full responsibility for the contents.
You really seriously just don't have any excuse for this sort of thing.
> There don't seem to be any specific vulnerabilities related to these permissions, though I'd like to see them go away.
Only someone working for Magento could claim 777 is ever not a hideously terrible idea to have in the webroot of a PHP application. This is frankly insane behaviour. It's like running applications as root in the general case and saying "well, we haven't found a vulnerability yet." YOU REALISE PEOPLE PUT REAL MONEY THROUGH THIS THING.
> It's my understanding that 777 will not exist in Magento 2.
I look forward to it.
Is this a download from the partner portal? I've asked support to check, but you can probably point out the source much more quickly than I can track it down.
> Only someone working for Magento could claim 777 is ever not a hideously terrible idea to have in the webroot of a PHP application
I did not make this claim. I stated that I wish it were not there. It's not necessary, as the kinds of environments in which 777 are necessary are a problem unto themselves. These instances are borne of legacy concerns which pre-date my arrival to Magento by 6 or 7 years. Pity they were not patched before now
Have you ever filed a bug report for this issue? I can imagine you might say, "I shouldn't have to," (and I agree), but it's remarkable what even a single ticket can do.
In general, it's unfortunate that Magento 1.x development and bug tracking are so... internal. In contrast to the visibility and interaction present at https://github.com/magento/magento2/issues it's clear that everyone is better off. Of course, we have to consider how to have the same kind of open dialogue for Enterprise Edition, and we're working out how to do that. Would you care to participate in a private GitHub repo, or can you suggest some other medium? Really, neither you nor I should have to spend time writing about the 777 issue - an open dialogue would likely have led this to be fixed years ago, so we could spend time bemoaning & fixing other issues!
I just did a global scan: still 100K shops are still unpatched today. According to builtwith.com, that's about 45% of the install base.
Joking aside, they are going to release 1.9.2 soon. For Magento 1 they're still doing feature releases, and they do patches for everything else because store owners do not like going through the upgrade process.
The only problem arises when people download fresh versions.
(or even worse; one-click installers on some shared web host... so they can't update it even if they wish!)
In fact, Magento issued two notification messages, on Friday and on Monday, so even if you applied the patch after seeing the first message, you still saw the second message and experienced that brief moment of panic.
Isn't that a bit redundant?
Cake lacks security expertise in their core team, unfortunately.
CodeIgniter is a bit conservative. (We must support PHP 5.2!) But then again, so is WordPress. They do listen to researchers.
Laravel is okay, but their lead dev is a bit of an egotistical and hypocritical ass. Recently, found and privately reported a PHP Object Injection vuln to Laravel; he said he didn't consider it a security issue, then when I disclosed publicly flipped his shit on me.
Symfony is great. Fabien has a cool head and responds well to security researchers.
Yii 2 is promising. I'll have to take another look before I call it bulletproof though.
My only experience with Zend has been interacting with their core devs on other media (Twitter, IRC); I haven't found any bugs in its core.
It comes down to how much time they can afford to spend on release testing for the OSS edition. They have tested the main release extensively, and have tested the patches too, but haven't had/made time to roll together a new full release and explicitly test that so continue to go with "install X, apply patches Y, Z, ..." as the process for new instances because that has been tested.
Full release regression testing can be a long-winded (and therefore potentially time expensive) process. Maybe people who have a problem with the current install process could club together and donate enough to make that worth while doing before the next planned full release...
(of course that is moot if people aren't warned adequately)
If you think I'm genuinely wrong please educate me rather than hitting "downvote" and running away...