SUPEE-9767, modman and symlinks

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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?