Nuova patch supee-6788 come applicare patch

29

Dopo settimane di attesa della patch oggi (27.10.2015) è stato rilasciato: SUPEE-6788

Molte cose sono state patchate ed è anche incoraggiato a rivedere i moduli installati per possibili vulnerabilità.

Apro questo post per ottenere alcuni approfondimenti su come applicare la patch. Quali sono i passaggi per applicare la patch? Per la mia comprensione, questi sono i passaggi:

Correggi i moduli con funzionalità di amministrazione che non si trova nell'URL di amministrazione
Correggi i moduli che utilizzano le istruzioni SQL come nomi di campo o campi di escape
White list block o direttive che utilizzano variabili come {{config path=”web/unsecure/base_url”}}e{{bloc type=rss/order_new}}
Affrontare il potenziale exploit con il tipo di file di opzioni personalizzato (non ho idea di come farlo)
Applica la patch

È questa la procedura corretta?

— lloiacono
fonte

1

Versioni CE attualmente elencate dalla 1.7.0.0 alla 1.9.2.0

— Fiasco Labs,

5

La patch cambia .htaccess.samplecosì come .htaccess. Quest'ultimo è personalizzato nella maggior parte dei negozi, questo farà fallire la patch => È necessario sostituirlo temporaneamente con il file originale di Magento, applicare la patch, ripristinare il proprio .htaccess e applicare la modifica che protegge l'accesso a cron.phpmanualmente (don ' ovviamente, per questo processo, uso il sistema di produzione!)

— Fabian Schmengler,

1

che dire di quelli che usano nginx?

— lloiacono,

4

Sto votando per chiudere questa domanda come fuori tema perché non ci sono domande. Sposta le discussioni in chat

— 7

2

C'è una domanda nel titolo stesso del post, anche nell'ultimo paragrafo sono più specifico. Indipendentemente da ciò, questo tipo di post è molto utile secondo me per centralizzare i commenti e le migliori pratiche quando si applica una patch appena rilasciata.

— lloiacono,

33

In generale, è possibile applicare la patch come tutte le precedenti. Dai un'occhiata alla documentazione ufficiale e controlla questo post SE . Sì, ci sono alcuni punti aggiuntivi che dovresti controllare quando applichi questa patch. Byte / Hypernode ha un bel post a riguardo.

Controlla se il tuo tema è personalizzato template/customer/form/register.phtmlo personalizzato template/persistent/customer/form/register.phtml. In tal caso, assicurarsi che includa a form_key.
Controlla se il tuo tema ha un'abitudine layout/customer.xml. In tal caso, assicurarsi di applicare le modifiche necessarie dalla patch ( customer_account_resetpasswordè stata modificata in customer_account_changeforgotten).
Usi variabili non standard in pagine CMS, blocchi statici o modelli di e-mail? Quindi assicurati di autorizzarli. Vedi questa domanda SE per sapere come autorizzare variabili / blocchi.
Esegui il cron.phpvia HTTP? Assicurati di usarlo meglio cron.sh. Se ciò non è possibile, assicurati almeno di chiamare cron.php tramite CLI PHP. Se per qualche motivo non puoi configurare un vero cronjob e devi eseguirlo via HTTP, vedi questa domanda SE
Assicurati che tutte le tue estensioni utilizzino il "nuovo" routing dell'amministratore. È possibile utilizzare questo plug-in n98-magerun per verificare. Puoi anche usare questo script CLI . Puoi anche dare un'occhiata a questa domanda SE relativa .
1. Quando tutte le estensioni utilizzano il routing dell'amministratore corretto, assicurati di disabilitare "Abilita modalità di compatibilità del routing dell'amministratore" in Sistema - Configurazione - Amministratore - Sicurezza.
Se usi M2ePro, aggiornalo all'ultima versione poiché le vecchie versioni non funzionano con la nuova patch.

Durante l'aggiornamento, assicurarsi di eliminare il file dev/tests/functional/.htaccess. Non è più presente in Magento 1.9.2.2. Mantenerlo significa che sei ancora vulnerabile.

In ogni caso, controlla la tua pagina con MageReport dopo l'aggiornamento per vedere se tutto è andato bene.

C'è anche un post sul blog tecnico di Piotr , che descrive i cambiamenti critici.

— Simon
fonte

Solo una piccola nota, lo script CLI menziona "Verifica che tutto vada bene, quindi disattiva la modalità di compatibilità del controller di amministrazione". Penso che significhino il contrario, per abilitarlo. È giusto?

— Michael,

1

@kaska Se tutte le tue estensioni sono a posto, devi disabilitare la modalità di compatibilità.

— Simon,

in un ambiente di produzione non dovresti rimuovere / dev completamente?

— paj,

1

@paj teoricamente sì. Ma con la versione 1.9.2.2, è protetto con un .htaccess, quindi dovrebbe essere corretto conservarlo. Assicurati solo di seguire il mio consiglio .htaccess sopra.

— Simon,

Grazie per la completezza, dovrebbero lasciarti scrivere le note di rilascio condensate la prossima volta! Super utile!

— asherrard,

6

Esiste un file di controllo che consente di identificare i problemi: https://github.com/gaiterjones/magento-appsec-file-check

Ne ho ricavato uno script CLI. https://github.com/Schrank/magento-appsec-file-check

— Fabian Blechschmidt
fonte

3

Per Nginx, assicurati di bloccare l'accesso a cron.php e alla cartella dev. Usiamo questo blocco:

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

— Adam L.
fonte

il tuo regex non funzionerà, perché controlli solo contro directory,. quindi "report / config.xml, cron.php" non corrispondono e hai una barra verticale o un simbolo di pipe alla fine .. copia-incolla? inoltre non confondere regex insieme a / app /, se sbagli qualcosa, verrà hackerato.

— MagenX,

Cattivo lavoro di copia e incolla, mi dispiace. Aggiunto in? alla fine, quindi la barra finale è facoltativa. Provato proprio ora e funziona come dovrebbe.

— Adam L.,

anche questa regex è vulnerabile, hai ^ /, assicurati di non copiare i tuoi file sorgente nella cartella principale, come / old /, / upgrade / etc

— MagenX,

@MagenX Quindi stai dicendo che se non usi il controllo della versione o l'amministrazione di sistema standard BCP, è colpa di questo regex?

— Melvyn,

1

Ho appena applicato la patch sul mio 1.10.1 EE e questo provoca effetti collaterali sugli schermi nativi perché il core non è compatibile con APPSEC-1063:

Esempio:

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

È possibile trovare 2 addFieldToFilterchiamate non conformi a APPSEC-1063.

Questo sta rompendo il cliente> Griglie degli attributi, quindi devi patchare la patch, usando il trucco che raccomandano nel pdf "SUPEE-6788-Technical% 20Details% 20.pdf" nella sezione APPSEC-1063

Cambiando i vari

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

(dove $ field contiene istruzioni sql complesse (CASE .. WHEN THEN ...)

in

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

Sia il super-6788-toolbox di rhoerr che i gaiterjones "non hanno rilevato questo tipo di problemi, ho controllato tutti gli altri -> addFieldToFilter ($ e nessuno sembra causare il problema.

Altri file core 1.10 interessati: (trovati dal supee-6788-toolbox di rhoerr)

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

Potrebbe essercene di più.

— FRACASSATO
fonte