Novo patch supee-6788 como aplicar o patch

29

Após semanas de espera pelo patch de hoje (27.10.2015), foi lançado: SUPEE-6788

Muitas coisas foram corrigidas e também é encorajado a revisar os módulos instalados quanto a possíveis vulnerabilidades.

Abro este post para obter algumas informações sobre como aplicar o patch. Quais são as etapas para aplicar o patch? Para meu entendimento, estas são as etapas:

Corrija os módulos com a funcionalidade de administrador que não está na URL do administrador
Corrija módulos que usam instruções SQL como nomes de campos ou campos de escape
Blocos de lista branca ou diretivas que usam variáveis como {{config path=”web/unsecure/base_url”}}e{{bloc type=rss/order_new}}
Abordando a exploração potencial com o tipo de arquivo de opção personalizada (não faço idéia de como fazer isso)
Aplique o patch

Esse é o procedimento correto?

— lloiacono
fonte

1

Versões atuais do CE listadas 1.7.0.0 a 1.9.2.0

— Fiasco Labs

5

O remendo muda .htaccess.sample, bem como .htaccess. Este último é personalizado na maioria das lojas, isso fará com que o patch falhe => Você precisa substituí-lo temporariamente pelo arquivo original do Magento, aplicar o patch, restaurar seu próprio .htaccess e aplicar a alteração que protege o acesso cron.phpmanualmente (não t usar o sistema de produção para este processo é claro)!

— Fabian Schmengler

1

e aqueles que usam o nginx?

— Lloiacono 27/10/2015

4

Estou votando para encerrar esta questão como fora de tópico, porque não há dúvida. Mova as discussões para o chat

— 7ochem 27/10/2015

2

Há uma pergunta no próprio título do post, também no último parágrafo eu sou mais específico. Independentemente disso, esse tipo de post é muito útil na minha opinião para centralizar comentários e práticas recomendadas ao aplicar um patch recém-lançado.

— Lloiacono 27/10/2015

33

Em geral, você pode aplicar o patch como todos os anteriores. Dê uma olhada na documentação oficial e verifique este post do SE . Mas sim, existem alguns pontos adicionais que você deve verificar ao aplicar esse patch. Byte / Hypernode tem um bom post sobre isso.

Verifique se o seu tema tem um costume template/customer/form/register.phtmlou costume template/persistent/customer/form/register.phtml. Se for esse o caso, verifique se ele inclui a form_key.
Verifique se o seu tema tem um costume layout/customer.xml. Se for esse o caso, certifique-se de aplicar as alterações necessárias do patch ( customer_account_resetpasswordfoi alterado para customer_account_changeforgotten).
Você usa variáveis não padrão em páginas do CMS, blocos estáticos ou modelos de email? Em seguida, verifique se você os colocou na lista de permissões. Veja esta pergunta SE para aprender como colocar variáveis / blocos na lista de permissões.
Você executa o cron.phpvia HTTP? Certifique-se de usar melhor cron.sh. Se isso não for possível, certifique-se de chamar o cron.php via CLI PHP. Se, por algum motivo, você não puder configurar um cronjob real e precisar executá-lo via HTTP, consulte esta pergunta SE
Verifique se todas as suas extensões usam o "novo" roteamento de administrador. Você pode usar este plugin n98-magerun para verificar. Você também pode usar este script da CLI . Você também pode dar uma olhada nesta pergunta relacionada ao SE .
1. Quando todas as suas extensões usarem o roteamento de administrador adequado, desative "Ativar o modo de compatibilidade de roteamento de administrador" em Sistema - Configuração - Admin - Segurança.
Se você usa o M2ePro, atualize-o para a versão mais recente, pois as versões antigas não funcionam com o novo patch.

Ao atualizar, exclua o arquivo dev/tests/functional/.htaccess. Não está mais presente no Magento 1.9.2.2. Mantê-lo significa que você ainda está vulnerável.

De qualquer forma, verifique sua página com o MageReport após a atualização para ver se tudo correu bem.

Há também uma postagem técnica no blog da Piotr , que descreve as mudanças críticas.

— Simon
fonte

Apenas uma pequena nota, o script da CLI menciona 'Verifique se tudo está bem e desative o modo de compatibilidade do controlador administrativo'. Eu acho que eles querem dizer o contrário, para permitir isso. Isso esta certo?

— Michael

1

@kaska Se todas as suas extensões estiverem corretas, você deverá desativar o modo de compatibilidade.

— Simon

em um ambiente de produção, você não deve remover / dev completamente?

— paj

1

@paj teoricamente sim. Mas com a versão 1.9.2.2, ele é protegido com um .htaccess, portanto, não há problema em mantê-lo. Apenas certifique-se de seguir meus conselhos sobre .htaccess acima.

— 29415 Simon

Obrigado pela integridade, eles devem deixar você escrever as notas de versão condensadas na próxima vez! Super útil!

— Asherrard #

6

Há um arquivo de verificação que ajuda a identificar problemas: https://github.com/gaiterjones/magento-appsec-file-check

Eu fiz um script CLI com isso. https://github.com/Schrank/magento-appsec-file-check

— Fabian Blechschmidt
fonte

3

Para o Nginx, certifique-se de bloquear o acesso ao cron.php e à pasta dev. Nós usamos este bloco:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

— Adam L.
fonte

seu regex não funcionará, pois você confere apenas o diretório,. então "report / config.xml, cron.php" não corresponde, e você tem um símbolo de barra ou tubo vertical no final. copiar e colar? também não mexa regex junto com / app /, se você colocar algo errado, ele será hackeado.

— MagenX 27/10/2015

Trabalho ruim de copiar e colar, desculpe. Adicionado no? no final, para que a barra final seja opcional. Testei agora e está funcionando como deveria.

— Adam L.

Também este regex é vulnerável, você tem ^ /, certifique-se que você não copiar os arquivos de origem para a pasta de topo, como / old /, / atualizar / etc

— MagenX

@MagenX Então, você está dizendo que, se você não usa o controle de versão ou o BCP de administração de sistema padrão, é a culpa deste regex?

— Melvyn

1

Acabei de aplicar o patch no meu 1.10.1 EE e isso causa efeitos colaterais nas telas nativas porque o núcleo não é compatível com APPSEC-1063:

Exemplo:

Em app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Você pode encontrar 2 addFieldToFilterchamadas não compatíveis com APPSEC-1063.

Isso está quebrando as grades Customer> Attribute, então você deve corrigir o patch usando o truque recomendado no pdf "SUPEE-6788-Technical% 20Details% 20.pdf" na seção APPSEC-1063

Mudando os vários

    $this->addFieldToFilter($field, 0);

(onde $ field contém instruções sql complexas (CASE .. WHEN THEN ...))

para dentro

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Tanto o supee-6788-toolbox como o gaiterjones não detectaram esse tipo de problema, verifiquei todos os outros -> addFieldToFilter ($ e nenhum parece estar causando o problema.

Outros arquivos principais do 1.10 afetados: (encontrados pela rhoerr's supee-6788-toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php

Pode haver mais.

— SMASHED
fonte