SUPEE-9767, modman e links simbólicos


16

Gostaria de consertar uma loja Magento com SUPEE-9767. A documentação do SUPEE-9767 diz para desativar a configuração dos Links simbólicos antes de aplicar o patch:

Antes de aplicar o patch ou atualizar para a versão mais recente, desabilite a configuração Symlinks ... A configuração, se ativada, substituirá a configuração do arquivo de configuração e a alteração exigirá modificação direta do banco de dados.

Mas eu uso o modman para gerenciar módulos e, como alguns módulos estão usando arquivos de modelo, a configuração Symlinks é ativada de acordo com a sugestão no README do modman. É seguro deixar a configuração de Symlinks ativada como uma das postagens no Patch de segurança SUPEE-9767 - Possíveis problemas? sugere (ainda não posso comentar sobre as postagens, pois sou um novo usuário)?

Os usuários que usam o modman para gerenciar os módulos Magento 1.x devem garantir que eles não desabilitem os links simbólicos, pois isso desabilitará os módulos modman.

Se eu deixar a configuração Symlinks ativada, a loja não seria exposta ao APPSEC-1281: Execução remota de código por meio de links simbólicos , uma ameaça à segurança que esse patch deve corrigir?

Existem outras maneiras de usar o modman com arquivos de modelo após esse patch? (Conheço a opção "versão corrigida do Mage / Core / Block / Template.php" que o README do modman menciona, mas corrigir um arquivo principal parece perigoso.)


1
Estou usando Modman e Composer em meus projetos. Não acredito por muitos anos que a opção Symlinks no Magento não foi considerada uma bomba. De repente, é uma bomba! Essa alteração sem notificações e explicações criará muitos problemas para muitas pessoas. Triste com o futuro de Modman e Compositor em Magento.
ADDISON74

1
Esse é o grande desafio. Se você estiver disposto a fazer o investimento, a criação de um processo de construção que gere um artefato mesclado (sem links simbólicos) é um caminho muito bom.
JavaScript é necessário para o funcionamento completo desta página

Um ótimo artigo sobre isso pode ser encontrado em tomlankhorst.nl/…, onde ele também explica como se livrar do aviso "Symlinks estão habilitados", introduzido no Magento 1.9.3.4.
ehannes

Respostas:


14

Aqui estão alguns esclarecimentos sobre essa alteração:

Leia pela primeira vez esta explicação de Peter O'Callaghan, para obter uma grande compreensão: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Também outra leitura interessante é esta postagem de Max Chadwick https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

Essa modificação é realmente sobre chamar conteúdo carregável (como imagens) por meio de diretivas de modelo.

O problema relacionado aos links simbólicos é explorável apenas com acesso de administrador, e o Magento também adicionou mais proteção aos envios de imagens.

Observe que existem algumas proteções contra a maneira conhecida de explorá-lo, além da própria configuração.

Portanto, se você entender o risco envolvido, poderá deixar os links simbólicos ativados.

Se você precisar habilitá-los para uma nova instalação, execute:

UPDATE core_config_data SET value = 1 WHERE path = "dev/template/allow_symlink";

Se eu deixar os links simbólicos ativados, como protegeria a loja contra "APPSEC-1281: Execução remota de código através dos links simbólicos"?
ehannes

@ehannes, protegendo o acesso ao seu back-end, pois a exploração requer acesso ao back-end. Além disso, o upload da imagem agora tem uma validação extra de retorno de chamada.
Raphael no Digital Pianism

3
obter acesso de administrador significa que você tem acesso a toda a interface de back-end do Magento. quem se importa com uma exploração nesta fase encontrada em um script de upload de imagem? esse usuário mal-intencionado pode excluir todos os seus produtos, pode fazer coisas inimagináveis. a discussão deve começar com "se este usuário tem direitos de administrador porque o verdadeiro administrador é estúpido não proteger a infra-estrutura de muitas maneiras"
ADDISON74


2
Peter O'Callaghan escreve: "Portanto, se alguém conseguir obter acesso ao seu painel de administração, poderá executar uma inclusão maliciosa para obter o RCE". Esta parece ser a conclusão comum nesta discussão. Como dito anteriormente, se um usuário mal-intencionado tiver acesso ao seu painel de administração, há outras coisas com que se preocupar além do RCE. Se alguém tiver algo a acrescentar à discussão, por favor. De qualquer forma, acho que você deixou as coisas muito mais claras @RaphaelatDigitalPianism e eu aceito essa resposta.
ehannes

6

O problema não é de links simbólicos, mas de caminhos que atingem níveis como ../../../../../media/tmp/hahaha.png. Se eu estiver errado, por favor, me esclareça. A "correção" foi intitulada "Permitir links simbólicos" e habilitar isso desabilita a verificação que foi implementada usando realpath(). Na minha opinião, uma correção igualmente segura, mais eficiente e ainda compatível com links simbólicos é usar strpos($path, '..')e / ou verificar se isso realpath()corresponde a certos diretórios arriscados como mediae var. Se implementado dessa maneira, não precisaria ser configurável; ele sempre poderia ser ativado e ainda assim não quebrar milhares de lojas.

Independentemente disso, o usuário do servidor da web não deve ter acesso para gravar arquivos nos diretórios de código-fonte (como o Magento Connect ...), portanto, é outra maneira de impedir que códigos maliciosos sejam gravados em algum lugar e executados como um modelo de bloco.

Portanto, esse ataque aos links simbólicos é mal direcionado e existe uma correção melhor. Na verdade, eu forneci um há mais de um ano e há até um link para ele no README do modman github.


0

Se, no extra do seu arquivo de compositor, você definir a estratégia magento-deploy para copiar seus arquivos, será copiado da pasta do fornecedor em vez de links simbólicos.

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

Você pode modificar seu core_config_data para definir o valor de dev / template / allow_symlink como 0

Recurso para informações


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.