-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Magento patch SUPEE-9767 and Symlinks setting #125
Comments
I'm running into the same issue. As a workaround I am using the |
I posted a question on Magento StackExchange concerning this issue. |
Are there any downsides using |
The only thing Magento did was to remove the system configuration in system.xml. For production use you can use the --copy flag. In development environment I would prefer symlinks. |
@ThomasNegeli They probably removed the Symlinks setting for security reasons, for instance APPSEC-1281: Remote code execution through symlinks. Even though you can still enable the setting, the question is if you should. How dangerous is it to have it enabled? |
@ehannes As stated by Piotr Kaminski in https://twitter.com/piotrekkaminski/status/870020878586617857 you will need admin access for this exploit to be a problem. |
@ThomasNegeli If that is the case, then why does Magento bothers to remove the feature in the first place? Anyhow, the README for modman needs to be updated since the Symlinks setting is removed in Magento 1.9.3.3 and after the SUPEE-9767 patch. |
I think the problem is that the original security fix was a bad one to begin with. The "Allow symlinks" option doesn't have anything to do with real symlinks, it just does a realpath comparison. I still after all of these years fail to see how simply allowing template files to be accessed via symlinks increases security risk, although I do see how using paths that reach outside of the Magento base path could be bad. If a malicious user can write a symlink then they can write a regular file as well. The real issue in my opinion (and I'd love for someone to explain to me if I'm wrong) is the risk of '..' being used in the template file paths. In this case rather than use |
So am I correct in the following analysis?
So it looks to me like I have the following choices: Unless (c) happens to have priority, all of these look like unhappy choices to me. I'm considering (d), but I'm not that experienced in Magento development yet and leery of core hacks unless absolutely necessary. However, a hack that actually simplifies long-term maintenance might be reasonable. Supposing I did choose (d), would this be a reasonable approach?
Into
|
I would recommend (d). The README already contains a link to a patched version of Template.php (although it is old the revision history shows the changed lines which are only a few). The location of the Option (e): let Magento folks know that their fix is unacceptable and request a follow-up patch that isn't so wreckless. (don't hold your breath) |
Thanks! I went with the Template patch and it's working nicely. |
If you're using a deployment tool to deploy your shop online (such as Deployer, Rocketeer, Capistrano, Deployhq, etc etc) setting the deploy strategy for Composer/Modman to For developing locally, using symlinks is nicer than copying them into the project. That's why we've added the |
--copy works unproperly so if you installed module with --copy key that when you need to remove this module you use modman remove Module or modman remove --copy Module |
@devzorg - do a |
@colinmollenhour is/was there a PR at LTS for the patched version of
Magentos update script for 1.9.3.4 removes this entry from DB and also added an config backend model that prevent changing/save this value from admin backend (if visible). If you want to use symlink (on your own risk) you can use https://github.com/sreichel/magento-Sr-AllowSymlink. It just brings back admin config option ... |
I just created a PR at Magento LTS project: OpenMage/magento-lts#442 |
A new Magento patch (SUPEE-9767 released yesterday, May 31 2017) suggests that you should disable Symlinks setting before applying the patch:
If you are managing modules by modman that use template files, these will not work as described in modman's README. I guess the reason for the suggestion of disabling Symlinks setting is the APPSEC-1281: Remote code execution through symlinks fix included in the patch.
How will this affect modman? If you need to have Symlinks setting enabled to use modman (if you do not want to patch
Mage/Core/Block/Template.php
as suggested in modman's README), this means your Magento shop is opened for at least one known security threat...The text was updated successfully, but these errors were encountered: