Patching.
Patch nuove, stesso PHP.
Prendiamo i pacchetti PHP già installati sui tuoi server e ci applichiamo le correzioni di sicurezza rilasciate dal team di sviluppo di PHP, adattate alla tua versione.
Così il tuo PHP continua a ricevere patch anche quando il progetto ufficiale non mantiene più il tuo ramo: stessa versione, stessi percorsi, stessa configurazione, senza toccare l’applicazione.
Il pacchetto originario.
Più le patch ufficiali.
Quando un ramo di PHP arriva alla fine del supporto, il team di sviluppo continua a correggere le vulnerabilità solo sui rami più recenti. Molte di quelle falle esistono anche nel codice dei rami vecchi: noi prendiamo le correzioni e le portiamo sul tuo.
Il PHP che hai già.
Il pacchetto installato sui tuoi server, da dove arriva: dalla distribuzione, da AppStream, da Remi, dalle Software Collections o da deb.sury.org. Non lo sostituiamo con un altro PHP.
Le correzioni del team PHP.
Le correzioni di sicurezza che gli sviluppatori di PHP scrivono, verificano con un test e pubblicano nel repository del progetto per i rami ancora supportati.
Il tuo PHP, patchato.
Le stesse correzioni adattate al tuo ramo e inserite nel tuo pacchetto. Stessa versione, stessi percorsi, stessa configurazione. Nel changelog, le CVE corrette.
Una CVE, un Moodle.
Tre mesi di tempo.
Un esempio animato, dall’avviso di sicurezza al nuovo server: Moodle su PHP 5.6 e CentOS 6.10, le correzioni portate sul pacchetto di Remi, il rilascio e la migrazione ad AlmaLinux 10. Scenario illustrativo.
Sei fasi.
Dalla CVE al pacchetto.
Per ogni correzione seguiamo la stessa sequenza che usano Red Hat, Debian, Ubuntu e SUSE per mantenere i pacchetti delle loro release stabili. La differenza è che noi la applichiamo anche ai rami che nessuno mantiene più.
Approfondisci il backport- 01
Analisi della vulnerabilità
Partiamo dall’avviso ufficiale e dalla correzione pubblicata nel repository di PHP. Verifichiamo se il codice vulnerabile esiste nel tuo ramo e se è raggiungibile sul tuo server: una falla di PHP-FPM non riguarda chi usa mod_php, una falla in un’estensione non caricata non è sfruttabile.
- 02
Correzione ufficiale
Prendiamo la modifica scritta dal team di sviluppo di PHP per i rami supportati, con il test che riproduce la falla quando esiste. È il punto di partenza: la logica della correzione è quella ufficiale.
- 03
Adattamento al tuo ramo
Tra PHP 5.6 e PHP 8 l’interprete è stato in gran parte riscritto. Una correzione di due righe può applicarsi quasi uguale, oppure va riscritta sul codice del ramo vecchio mantenendo lo stesso controllo. È il lavoro che richiede esperienza sul sorgente di PHP e che non si automatizza.
- 04
Ricostruzione del pacchetto
Inseriamo la patch nel pacchetto che il server usa già, RPM o DEB. Ricostruire da quel pacchetto mantiene identici nomi, percorsi, file di configurazione ed estensioni, e cambia solo il numero di release.
- 05
Test
Eseguiamo i test automatici di PHP, compreso quello che riproduce la falla, e proviamo la tua applicazione reale in un ambiente di prova il più simile possibile alla produzione.
- 06
Rilascio con rollback
Distribuiamo il pacchetto con Ansible su uno o cento server e riavviamo i processi PHP in modo coordinato. Il ritorno alla versione precedente è pronto prima del rilascio.
Stesso PHP.
Senza le falle.
Un PHP patchato si presenta con la stessa versione di prima. Cambia solo la parte del numero gestita da chi mantiene il pacchetto, e il changelog elenca le CVE corrette. Red Hat fa lo stesso: php-fpm-5.4.16-46.1.el7_7 resta PHP 5.4.16 e corregge la CVE-2019-11043.
# La versione di PHP resta quella di prima$ php -vPHP 5.6.40 (cli) …# Cambia la release del pacchetto: i nostri terminano con .ms1$ rpm -q php-common php56-php-common# Le CVE corrette sono elencate nel changelog$ rpm -q --changelog php-common | grep -E 'CVE-2024-8925|CVE-2026-109619'# Su Debian e Ubuntu: suffisso della versione e changelog del pacchetto$ dpkg-query -W -f='${Version}\n' php7.0-fpm$ zcat /usr/share/doc/php7.0-fpm/changelog.Debian.gz | grep -i cveNon cambia
- La versione di PHP:
php -vmostra lo stesso numero - Nomi dei pacchetti, percorsi e file di configurazione
- Estensioni installate e loro impostazioni
- Il comportamento della tua applicazione
Cambia
- Il numero di release del pacchetto RPM o il suffisso del DEB
- Il changelog, con l’elenco delle CVE corrette
- Il codice di PHP nel punto preciso in cui c’era la falla
PHP 5.6.40-41.ms1.
55 CVE corrette.
L’ultimo rilascio ufficiale di PHP 5.6 è del gennaio 2019. Il nostro pacchetto per Enterprise Linux 6, nelle famiglie php-* e php56-php-*, corregge 55 CVE: 44 ereditate dai sorgenti Remi e 11 aggiunte da noi con backport dedicati.
Un’urgenza oggi.
O una CVE dopo l’altra.
Si parte da una valutazione tecnica: versioni, distribuzioni, numero di server ed esposizione. L’obiettivo di 24 ore riguarda l’intervento d’urgenza su una singola CVE e viene confermato dopo la valutazione.
Intervento d’urgenza
Una CVE da chiudere adesso.
- Analisi dell’esposizione e mitigazioni immediate
- Backport della patch sul tuo ramo
- Pacchetto per la tua distribuzione, test e rilascio
- Obiettivo di 24 ore dall’analisi al rilascio
- Reperibilità H24: +39 340 985 4556
Supporto esteso
PHP 5.4 – 8.1, una CVE dopo l’altra.
- Monitoraggio degli avvisi di PHP e delle distribuzioni
- Backport dedicati a ogni nuova CVE che ti riguarda
- Pacchetti aggiornati per tutti i server, RPM e DEB
- Rilasci programmati e coordinati
- Report per audit, NIS2 e ISO 27001
Cosa il patching
non può fare.
Il patching chiude vulnerabilità specifiche e note. Ha limiti precisi, ed è giusto conoscerli prima di sceglierlo.
Non rende il ramo supportato
Ogni nuova CVE va valutata e, se riguarda il tuo ramo, corretta con un nuovo intervento. Il supporto esteso serve proprio a questo.
Non risolve la compatibilità
Librerie Composer, SDK di pagamento e nuove versioni dei CMS continuano a richiedere PHP 8: per quello c’è l’App Upgrading.
Non copre le librerie di sistema
OpenSSL, libxml2, ICU e le altre librerie usate da PHP seguono il sistema operativo, e su un sistema fuori supporto vanno considerate a parte.
Non corregge l’applicazione
Una SQL injection nel codice del sito o una falla in un plugin non dipendono dalla versione di PHP.
Non sempre è possibile per intero
Quando la correzione completa stravolgerebbe il codice del ramo, applichiamo una mitigazione e la dichiariamo come tale nel changelog.
Il patching protegge la produzione oggi. L’App Upgrading toglie il problema domani.
App UpgradingPer approfondire.
Backport delle patch di sicurezza: cos’è e come protegge una versione di PHP fuori supporto
Cosa significa portare una correzione scritta per PHP moderno su un ramo in End of Life, come lo fanno da sempre le distribuzioni Linux, come si costruisce e si verifica il pacchetto e cosa il backport non può fare.
Leggi l’approfondimentoLe 55 CVE corrette su PHP 5.6.40: cosa abbiamo trovato e come le abbiamo chiuse
Dentro il nostro pacchetto PHP 5.6.40-41.ms1 per EL6: le 55 CVE corrette, 44 ereditate dai sorgenti Remi e 11 aggiunte con backport dedicati, cosa cambia per chi lo installa e come verificarlo sul server.
Leggi l’approfondimentoCosa fare nelle prime 24 ore dopo una CVE critica su PHP
Triage, mitigazioni temporanee, backport della patch, test con l’applicazione reale, rilascio con Ansible e piano di rollback: la sequenza di un intervento d’urgenza su una vulnerabilità critica di PHP fuori supporto, ora per ora.
Leggi l’approfondimentoPrima di iniziare.
Le domande che ci fanno più spesso su patch, verifiche e scanner di sicurezza.
Le patch sono ufficiali?
La correzione nasce dal team di sviluppo di PHP: partiamo dalla modifica pubblicata nel repository del progetto per i rami supportati. L’adattamento al tuo ramo e il pacchetto sono nostri, e il changelog dice per ogni CVE cosa è stato fatto, comprese le eventuali mitigazioni.
Come verifico che le correzioni ci siano?
Con il gestore dei pacchetti: rpm -q --changelog sugli RPM o il changelog del pacchetto sui DEB elencano le CVE corrette. La release dei nostri pacchetti RPM termina con .ms1.
Lo scanner continua a segnalare PHP obsoleto: perché?
Molti scanner leggono solo il numero di versione, che con il backport non cambia, e producono falsi positivi. La risposta corretta al report è il changelog del pacchetto con le CVE corrette: te lo forniamo pronto per l’audit.
Serve fermare il sito?
No. Il pacchetto si installa come un normale aggiornamento e i processi PHP vengono riavviati in modo coordinato. Se qualcosa non va, si torna alla versione precedente reinstallando il pacchetto di prima.
Per quanto tempo si può andare avanti così?
Il tempo che serve a migrare con calma. Il patching tiene al sicuro la produzione oggi, ma non rende il ramo supportato: l’obiettivo resta portare l’applicazione su PHP 8.x.
Mettiamo
in sicurezza.
Indicaci versione di PHP, distribuzione e origine dei pacchetti. Ti risponderemo con una valutazione dell’esposizione e una proposta di intervento.
Richiedi una valutazioneLunedì – venerdì · 09:30 – 19:30
+39 340 985 4556 ↗