
Magento eCommerce PHP Remote Code Execution - Mojah
https://ma.ttias.be/magento-ecommerce-php-remote-code-execution
======
mrweasel
Unless it got significantly better/redesigned in the last couple of years,
Magento is a piece of junk.

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.

~~~
jlas
Magento code in general is of very dubious quality. I once ran a quick static
analysis on it and found some ridiculous results:
[https://twitter.com/jlas_/status/391615992473722880](https://twitter.com/jlas_/status/391615992473722880)

~~~
Someone1234
While it could be better written, that's just their installer, it doesn't run
in production by its very nature so might be a low priority for coding
standards.

If you wanted to call them out, at least call them out for something which
actually runs during normal operation.

~~~
davidgerard
Whoever wrote Magento thinks 777 permissions are ever the right thing to do.

Every book I've ever seen on Magento seems to think the same. That 777
permissions are _just not a big deal_.

~~~
benmarks
From [http://devdocs.magento.com/guides/m1x/install/installer-
priv...](http://devdocs.magento.com/guides/m1x/install/installer-
privileges_before.html) :

"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-------)."

~~~
davidgerard
From the Magento Enterprise tarball, which we pay enormous sums of money for:
[https://news.ycombinator.com/item?id=9417235](https://news.ycombinator.com/item?id=9417235)

------
jay-saint
Admin and developer of two Magento based sites here.

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](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/](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.

~~~
jay-saint
One extra note for those who may run their Magento install on a shared host.
You will likely not be able to use the patch as is. It is distributed as .sh
file that requires SSH and permissions that are not available on most shared
hosts. This is a serious shortfall of this patching method. You should create
a trouble ticket with support and they should be able to run the patch scripts
for you.

~~~
teh_klev
I agree for the most part here. But it's not totally insurmountable. Patch
against your local development and/or staging copy then upload the changed
files to your shared host.

------
devy
Dutch's largest Magento hosting company Byte released a online testing tool:
shoplift.byte.nl

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.

~~~
tokenizerrr
"Dutch's"? I assume you mean the Netherlands since Dutch is the language, not
a country or anything. This would be the same as saying "English's largest
Magento ...". Alternatively you could say "The largest Dutch Magento ..."

~~~
devy
Thanks.

------
davidgerard
> It boggles my mind why Magento would willingly distribute unsafe code this
> way, assuming users would just find out to download the patches separately.

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);

~~~
benmarks
The first two are a third party module. If 0777 is objectionable then I'm
surprised you are using the module or haven't at least patched it - not trying
to snark, just wondering if there's some additional context.

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.

~~~
davidgerard
>The first two are a third party module.

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.

~~~
benmarks
> _As I said: Magento Enterprise tar ball, supplied at considerable expense
> straight from Magento._

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](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!

------
xylodev
Regardless the way Magento releases the patches, the most annoying thing is
hiding them behind the login form, making it impossible to apply from the
console. You can install Magento via SSH, but you cannot apply security
patches the same way - I am not able to understand this. I know, there's a
business behind this, but open source in Magento meaning is somehow strange.

------
ratsz
There's been 10 patches (2 with remote code execution exploits) and no version
bump. Are they trying to make it seem like their product is more secure or
stable by not incrementing the version?

------
dante9999
Where can one find analysis of this vulnerability? There are no details in
checkpost blogpost revealing vulnerability. I assume its serious and real if
magento releases patches but would be cool to be able to judge myself.

~~~
D3ve1inE
It will be released in the next day or 2 so people will have time patching up
their systems.

------
gwillem
Vuln tester @ [https://shoplift.byte.nl](https://shoplift.byte.nl)

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.

------
ebbv
This is hardly unique to Magento. Lots of applications do this. It's not
ideal, but it's not SO bad _if_ the application nags you to patch on start up.
I don't use Magento, so I'm not sure if it does.

~~~
NietTim
It does, and looks like this, a screen filling alert view when you login into
the backend. [http://i.imgur.com/yeBKQIM.png](http://i.imgur.com/yeBKQIM.png)

~~~
ErrantX
It's the wordpress problem; Magento has made e-commerce accessible to anyone
with a shared webspace and the minimum of knowledge (speaking as someone who's
company integrates with small businesses who use Magento). So it's very easy
for things to get out of date.

(or even worse; one-click installers on some shared web host... so they can't
update it even if they wish!)

------
sarciszewski
Would anyone be interested if I were to host a maintained fork of the Magento
community edition on github with up-to-date security patches so you can just
`git pull` and be done with it?

~~~
Navarr
The only problem with that is you have to fork off that for your own Magento
site and it basically doesn't help anyone that doesn't already know what
they're doing and patch right away already. :\

~~~
sarciszewski
True, and it's unlikely that they would update their website to encourage this
approach since their incentive is to get people to pay them instead.

------
tphan
Magento is pretty old school. Things like patching will be much easier in
Magento 2, which uses Composer for managing dependencies.

~~~
madaxe_again
Yes. And that non-existent upgrade path sure is pretty sweet, and sure isn't
going to make people look elsewhere...!

------
geekamongus
I smell the lawyers coming.

------
emergentcypher
"Unsafe PHP"

Isn't that a bit redundant?

~~~
sarciszewski
As someone who routinely finds security bugs in popular PHP frameworks... no,
it really isn't.

~~~
BringTheTanks
What's your opinion on "popular frameworks".

~~~
sarciszewski
They vary; generally, their maintainers mean well but that doesn't necessarily
translate to secure code.

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.

~~~
Phil_Latio
Looks like after your "evil" public disclosure, they now added security
contact:
[https://github.com/laravel/framework/commit/69e5c3c1daca8454...](https://github.com/laravel/framework/commit/69e5c3c1daca84549a15ce3a96021ec914bf002a)

~~~
sarciszewski
Yes, but I originally emailed that address so I don't think it was a reaction
to me (or even a passive aggressive gesture). Taylor had a week's heads up and
chose to dismiss my report.

------
dspillett
I don't see the big fuss here if people are warned, either as the main package
is downloaded or in the post-install configurations screens or in the admin
screens, or ...

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)

~~~
dspillett
A downvote with no explanation just tells me I've got on your nerves and you
aren't mature enough to discus it openly.

If you think I'm genuinely wrong please educate me rather than hitting
"downvote" and running away...

