Mantenersi l’infrastruttura di un’applicazione in casa è un rischio

Mantenersi l’infrastruttura di un’applicazione in casa è un rischio

input-output
Ciao! Benvenuta/o su Input/Output: la blogletter settimanale in cui ogni martedì commento la notizia che mi ha più colpito del mondo tech.

E ne hanno pagato le conseguenze i mantainer del linguaggio PHP che ieri si sono visti aggiungere due commit malevoli alla branch di sviluppo della versione 8.1 in uscita a fine anno.

Fortunatamente, grazie al processo di code review di ogni commit, è stato possibile individuare e correggere in poche ore il problema impedendo quindi che il codice venisse rilasciato nonostante i due commit fossero stati inviati utilizzando gli account di Rasmus Lerdorf e Nikita Popov (due autorità per quanto riguarda il linguaggio PHP).

Uno dei commit malevoli inviato usando l'account di Nikita Popov

Come sia potuta accadere una cosa del genere non è ancora chiaro ma si sospetta che il colpevole possa essere il vecchio server git su cui era ospitato il repository del linguaggio. Questo vecchio server era gestito “in casa” direttamente dai responsabili di PHP che ne curavano la manutenzione gli aggiornamenti e che gestivano l'amministrazione dei permessi con un progetto sviluppato ad-hoc per il servizio chiamato "Karma".

Per tagliare la testa al toro è stato deciso di dismettere immediatamente il vecchio server per passare ad un servizio specializzato nella gestione di repository git come GitHub. In modo che i mantainer possano concentrarsi solo nello sviluppo del linguaggio senza dover dedicare attenzione al mantenimento dell'infrastruttura su cui è ospitato il repository.

Al di là degli effetti catastrofici che un attacco del genere avrebbe potuto causare alle applicazioni scritte in PHP (circa il 79% di tutte quelle web), di questa storia ci sono due aspetti che mi hanno colpito particolarmente.

Il primo è che ha ribadito l’importanza di avere un processo di code review in modo che ci siano sempre almeno quattro occhi ad ispezionare ogni modifica al codice prima del rilascio in modo da garantirne la qualità e, come in questo caso, l'assenza di vulnerabilità.

Il secondo aspetto è legato alla comodità dei servizi Platform-as-a-Service (Paas) a cui è possibile delegare completamente la gestione dell'infrastruttura dell'applicazione. In molti ambiti si dice che “se una cosa funziona allora non si tocca”. Questo motto è quanto di più sbagliato esista nel mondo dell'informatica visto il ritmo estenuante con cui vengono rilasciati aggiornamenti e patch di sicurezza. Per cui quello che oggi funziona ed è sicuro rischia di essere vulnerabile domani se non ha personale dedicato che segue attentamente il ciclo di sviluppo del software. Molto spesso si preferisce tenere il server che ospita l'applicazione "nello scantinato" per risparmiare i soldi che un provider cloud richiede per lo stesso servizio senza intuire quali sono i vantaggi derivanti dall'investimento.

https://news-web.php.net/php.internals/113838


Grazie per aver letto questo articolo della rubrica Input/Output. Ad ogni input, tipicamente, corrisponde un output. E solo esponendosi ad input diversi si possono tirare fuori idee non convenzionali. Proprio per questo ogni martedì prendo in input una curiosità legata al mondo tecnologico per ragionare su nuove idee da tirare fuori in output.