17

I would like to patch a Magento shop with SUPEE-9767. The documentation for SUPEE-9767 tells me to disable Symlinks setting before applying the patch:

Before applying the patch or upgrading to the latest release, make sure to disable Symlinks setting ... The setting, if enabled, will override configuration file setting and changing it will require direct database modification.

But I use modman to manage modules and since some of the modules are using template files, the Symlinks setting is enabled according to the suggestion in modman's README. Is it safe to leave Symlinks setting enabled as one of the posts in Security Patch SUPEE-9767 - Possible issues? suggests (I cannot comment on posts yet since I'm a new user)?

Users using modman to manage Magento 1.x modules should ensure that they do not disable symlinks as this will disable the modman modules.

If I leave Symlinks setting enabled, wouldn't the shop be exposed to APPSEC-1281: Remote code execution through symlinks, a security threat this patch is meant to fix?

Are there other ways of using modman with template files after this patch? (I know of the "patched version of Mage/Core/Block/Template.php" option that modman's README mentions, but patching a core file seems dangerous.)

  • 1
    I am using Modman and Composer in my projects. I can't believe for many years Symlinks option in Magento was not considered a bomb. Suddenly it is a bomb! This change without any notifications and explanations will create a lot of trouble to many people. Sad about Modman and Composer future in Magento. – ADDISON74 Jun 1 '17 at 17:22
  • 1
    That is quite the challenge. If you are willing to make the investment, creating a build process that generates a merged (with no symlinks) artifact is a really nice way to go. – Joseph at SwiftOtter Jun 2 '17 at 21:14
  • A great article about this can be found at tomlankhorst.nl/… where he also explains how to get rid of the "Symlinks are enabled"-warning introduced in Magento 1.9.3.4. – ehannes Sep 11 '17 at 9:57
14

Here are some clarifications regarding this change:

First read this explanation from Peter O'Callaghan this will give you great understanding: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Also another interesting read is this post by Max Chadwick https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

This modification is really about calling uploadable content (like images) via template directives.

The issue related to symlinks is exploitable only with admin access and Magento added some more protection around image uploads as well.

Please note that they are some protections against known way to exploit it in addition to the setting itself.

So if you understand the risk involved, you can leave symlinks enabled.

If you need to enable them for a fresh install you can run:

UPDATE core_config_data SET value = 1 WHERE path = "dev/template/allow_symlink";
  • If I leave it symlinks enabled, how would I protect the shop against "APPSEC-1281: Remote code execution through symlinks"? – ehannes Jun 1 '17 at 12:24
  • @ehannes by protecting acces to your backend to start with as the exploit requires backend access. On top of that the image upload now has an extra callback validation. – Raphael at Digital Pianism Jun 1 '17 at 12:25
  • 3
    getting admin access means you have access to the whole Magento backend interface. who cares about an exploit at this stage found in an uploading image script? that malicious user can delete all your products, can do unimaginable things. the discussion should start with "if this user gets admin rights because the true admin is stupid not protecting the backend in many ways" – ADDISON74 Jun 1 '17 at 17:15
  • 1
  • 2
    Peter O'Callaghan writes: "Therefore if somebody manages to gain access to your admin panel, they can perform a malicious include to achieve RCE.". This seems to be the common conclusion in this discussion. As said before, if a malicious user has access to your admin panel, there are other things to worry about than RCE. If anyone has something to add to the discussion, please do. Anyhow, I think you have made things a lot clearer @RaphaelatDigitalPianism and I'll accept this answer. – ehannes Jun 2 '17 at 5:53
6

The issue is not symlinks, the issue is paths that reach up levels such as ../../../../../media/tmp/hahaha.png. If I am wrong on this please enlighten me. The "fix" was titled "Allow symlinks" and enabling this disables the check which was implemented using realpath(). In my opinion a fix that is just as secure, more performant and still compatible with symlinks is to use strpos($path, '..') and/or to check that the realpath() matches certain risky directories like media and var. If implemented like this it wouldn't need to be configurable it could just always be enabled and still not break thousands of stores.

Regardless, your web server user should not have access to write files in the source code directories (like Magento Connect does...) so that is another way to prevent malicious code being written somewhere and executed as a block template.

So, this attack on symlinks is just misdirected and a better fix exists. In fact, I provided one over a year ago and there is even a link to it in the modman github README.

0

If in the extra of your composer file you set magento-deploystrategy to copy your files will be copied from the vendor folder rather than Symlinks.

    "extra":{
        "magento-root-dir":"./",
        "magento-deploystrategy":"copy",
        "magento-force": true
    }

You can then modify your core_config_data to set the value of dev/template/allow_symlink to 0

Resource For Information

0

Are there other ways of using modman with template files after this patch?

You can override SUPEE-9767 changes in different ways, see:

How to enable symlinks after SUPEE-9767 V2 install?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.