9 ms·

Magento eCommerce PHP Remote Code Execution

143 points by Mojah 12y ago

tphan 12y ago
Magento is pretty old school. Things like patching will be much easier in Magento 2, which uses Composer for managing dependencies.
- madaxe_again 12y ago
  Yes. And that non-existent upgrade path sure is pretty sweet, and sure isn't going to make people look elsewhere...!
geekamongus 12y ago
I smell the lawyers coming.
ebbv 12y ago
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.
- smt88 12y ago
  What's bad is that it's so easy to fix. It's the distribution platform for software. Shouldn't there be lots of interested people that could take 20 minutes and write some software to fix this problem?
  - toxican 12y ago
    But they did, didn't they? There's a security patch and they're nagging people to install it. What are they failing to do?
    - onli 12y ago
      Normally, if you have a security patch you release a new version containing that patch. 1.9.0 -> 1.9.1.
      - Navarr 12y ago
        No see 1.9.1 has the Configurable Swatches in it. 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.
- NietTim 12y ago
  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 12y ago
    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!)
  - DCoder 12y ago
    That alert is shown because Magento issued a notification message, not because the system detected some security patches. Those two security patches were published on 2015 February 09 and 2014 October 03. 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.
- brianmwaters_hn 12y ago
  Yes. Among them, Vim, Bash, and OpenBSD, the latter of which supposedly has a very good reputation on security.
dspillett 12y ago
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 12y ago
  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...
jay-saint 12y ago
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 12y ago
  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 12y ago
    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.
- benmarks 12y ago
  Doing my best to get a 100% marketing-free mailing list for notifications in place soon.
mrweasel 12y ago
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.
- Navarr 12y ago
  The team has been working on a rewrite "Magento 2" that should alleviate most of the complaints of the original Magento and adopts PHP development best practices (composer, etc). 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] [1]: https://github.com/magento/magento2/issues/1051 https://github.com/magento/magento2/issues/1051 [2]: http://devdocs.magento.com/ http://devdocs.magento.com/
  - davidgerard 12y ago
    Are they still taking the "lucky sevens" approach to file permissions?
    - benmarks 12y ago
      See my comment above.
- jlas 12y ago
  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
  - mrweasel 12y ago
    That's somewhat terrifying
sarciszewski 12y ago
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 12y ago
  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 12y ago
    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.
- d_rbn 12y ago
  This already exists here: https://github.com/OpenMage/magento-mirror https://github.com/OpenMage/magento-mirror
emergentcypher 12y ago
"Unsafe PHP" Isn't that a bit redundant?
- hullo 12y ago
  No.
- sarciszewski 12y ago
  As someone who routinely finds security bugs in popular PHP frameworks... no, it really isn't.
  - BringTheTanks 12y ago
    What's your opinion on "popular frameworks".
    - sarciszewski 12y ago
      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.
      - BringTheTanks 12y ago
        Thanks, this was informative :)
      - Phil_Latio 12y ago
xylodev 12y ago
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.
devy 12y ago
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.
- dewey 12y ago
  Thanks for the test link, just applied the patch to a site I'm managing.
- tokenizerrr 12y ago
  "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 12y ago
    Thanks.
- rakk 12y ago
  We run some shops at Byte and were able to quickly apply the patches back in February. This week we got an e-mail from a worried customer who got a message in the back-end (from Magento) that his site might be vulnerable: 2 month's later.. 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.
- benmarks 12y ago
  Link to the referenced blog post? We absolutely do have tests for 1.x and have for years.
ratsz 12y ago
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?
T3RMINATED 12y ago
Magento is so slow.
dante9999 12y ago
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 12y ago
  It will be released in the next day or 2 so people will have time patching up their systems.
davidgerard 12y ago
> 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 12y ago
  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 12y ago
    >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.
gwillem 12y ago
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.

143 points by Mojah 12y ago

tphan 12y ago

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

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

geekamongus 12y ago

I smell the lawyers coming.

ebbv 12y ago

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.

smt88 12y ago
What's bad is that it's so easy to fix. It's the distribution platform for software. Shouldn't there be lots of interested people that could take 20 minutes and write some software to fix this problem?
- toxican 12y ago
  But they did, didn't they? There's a security patch and they're nagging people to install it. What are they failing to do?
  - onli 12y ago
    Normally, if you have a security patch you release a new version containing that patch. 1.9.0 -> 1.9.1.
    - Navarr 12y ago
      No see 1.9.1 has the Configurable Swatches in it. 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.
NietTim 12y ago
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 12y ago
  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!)
- DCoder 12y ago
  That alert is shown because Magento issued a notification message, not because the system detected some security patches. Those two security patches were published on 2015 February 09 and 2014 October 03. 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.
brianmwaters_hn 12y ago
Yes. Among them, Vim, Bash, and OpenBSD, the latter of which supposedly has a very good reputation on security.

dspillett 12y ago

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 12y ago
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...

jay-saint 12y ago

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 12y ago
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 12y ago
  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.
benmarks 12y ago
Doing my best to get a 100% marketing-free mailing list for notifications in place soon.

mrweasel 12y ago

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.

Navarr 12y ago
The team has been working on a rewrite "Magento 2" that should alleviate most of the complaints of the original Magento and adopts PHP development best practices (composer, etc). 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] [1]: https://github.com/magento/magento2/issues/1051 https://github.com/magento/magento2/issues/1051 [2]: http://devdocs.magento.com/ http://devdocs.magento.com/
- davidgerard 12y ago
  Are they still taking the "lucky sevens" approach to file permissions?
  - benmarks 12y ago
    See my comment above.
jlas 12y ago
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
- mrweasel 12y ago
  That's somewhat terrifying

sarciszewski 12y ago

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 12y ago
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 12y ago
  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.
d_rbn 12y ago
This already exists here: https://github.com/OpenMage/magento-mirror https://github.com/OpenMage/magento-mirror

emergentcypher 12y ago

"Unsafe PHP" Isn't that a bit redundant?

hullo 12y ago
No.
sarciszewski 12y ago
As someone who routinely finds security bugs in popular PHP frameworks... no, it really isn't.
- BringTheTanks 12y ago
  What's your opinion on "popular frameworks".
  - sarciszewski 12y ago
    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.
    - BringTheTanks 12y ago
      Thanks, this was informative :)
    - Phil_Latio 12y ago

xylodev 12y ago

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.

devy 12y ago

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.

dewey 12y ago
Thanks for the test link, just applied the patch to a site I'm managing.
tokenizerrr 12y ago
"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 12y ago
  Thanks.
rakk 12y ago
We run some shops at Byte and were able to quickly apply the patches back in February. This week we got an e-mail from a worried customer who got a message in the back-end (from Magento) that his site might be vulnerable: 2 month's later.. 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.
benmarks 12y ago
Link to the referenced blog post? We absolutely do have tests for 1.x and have for years.

ratsz 12y ago

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?

T3RMINATED 12y ago

Magento is so slow.

dante9999 12y ago

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 12y ago
It will be released in the next day or 2 so people will have time patching up their systems.

davidgerard 12y ago

> 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 12y ago
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 12y ago
  >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.

gwillem 12y ago

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.