Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Magento eCommerce PHP Remote Code Execution

ma.ttias.be

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Magento eCommerce PHP Remote Code Execution

#71

Post by benmarks »

davidgerard wrote: post #66
Navarr wrote: post #16

Earlier quoted context omitted.

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 wit…

Are they still taking the "lucky sevens" approach to file permissions?

See my comment above.

Re: Magento eCommerce PHP Remote Code Execution

#72

Post by benmarks »

jay-saint wrote: post #8

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 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…

Doing my best to get a 100% marketing-free mailing list for notifications in place soon.

Re: Magento eCommerce PHP Remote Code Execution

#73

Post by davidgerard »

benmarks wrote: post #70
davidgerard wrote: post #65

Earlier quoted context omitted.

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 .

From http://devdocs.magento.com/guides/m1x/install/installer-priv... : "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-------)."

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

Re: Magento eCommerce PHP Remote Code Execution

#74

Post by benmarks »

devy wrote: post #34

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.

Link to the referenced blog post? We absolutely do have tests for 1.x and have for years.

Re: Magento eCommerce PHP Remote Code Execution

#75

Post by benmarks »

davidgerard wrote: post #60

> 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.p…

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.

Re: Magento eCommerce PHP Remote Code Execution

#76

Post by davidgerard »

benmarks wrote: post #75
davidgerard wrote: post #60

> 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.p…

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.

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

Re: Magento eCommerce PHP Remote Code Execution

#77

Post by benmarks »

nightclubsub wrote: post #45
Raphmedia wrote: post #33

Earlier quoted context omitted.

It's not that bad once you wrap your head around it. 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.

It's not, developers just bear with it because they don't know of better alternatives. 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

Not really accurate to say that Magento is "built on top of... Zend." We don't use much of it.

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/

Re: Magento eCommerce PHP Remote Code Execution

#78

Post by benmarks »

mrweasel wrote: post #14

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…

Speaking to your points, in turn:

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

Re: Magento eCommerce PHP Remote Code Execution

#79

Post by madaxe_again »

tphan wrote: post #2

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

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

Re: Magento eCommerce PHP Remote Code Execution

#80

Post by benmarks »

davidgerard wrote: post #76
benmarks wrote: post #75

Earlier quoted context omitted.

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.

>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…

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

Post reply on HN