Ricapitoliamo: qualcuno è riuscito ad accedere ad uno dei server che supportano la distribuzione di WordPress ed ha inserito una backdoor nel codice distribuito. Poi, qualcuno di quelli che hanno scaricato wordpress se n’è accorto e l’ha segnalato agli sviluppatori, che hanno preso provvedimenti. È stata toccata solo la versione sul sito per la distribuzione, e non quella di sviluppo gestita con Subversion.
Come dice la pagina sul sito di WordPress, è una di quelle cose che vorresti non succedessero mai… ma è anche una di quelle cose che sai che potrebbero succedere, e per le quali devi essere preparato. In passato ci sono stati casi illustri, che hanno coinvolto ogni genere di aziende, e non solo il mondo open source. Questo sarebbe il tipico problema che i meccanismi di firma del software sono destinati a risolvere, e l’unico che secondo me riescono a risolvere bene. Al limite, può andare bene anche la pubblicazione dell’hash del codice, purché la pubblicazione avvenga in un contesto che difficilmente può essere violato quando viene manomesso il codice: pubblicare codice ed hash nella stessa directory è sostanzialmente inutile.
Tuttavia, la firma del software è un meccanismo che funziona solo se è diffuso ed affidabile: se troppo software non lo utilizza, o se chi lo utilizza spesso sbaglia, il meccanismo non è efficace, perché l’utente si abitua ad installare software non firmato o che genera warning. Mentre chi firma il software raramente firma il codice sbagliato, è successo piuttosto spesso che venissero utilizzate chiavi che il sistema di verifica previsto non riconosceva come valide. A me è successo qualche anno fa con chiavi di Microsoft Europe, e mi succede con una certa frequenza con chiavi pgp di firma degli rpm.
Comunque sia, WordPress non usa niente, nè firma nè hash. In questo caso, la sicurezza del sistema diventa fondamentale (ma rimane comunque un’alternativa di ripiego). Anche in questo caso, la funzione da svolgere è semplice: niente form, database o cose strane, possono essere richiesti via http alcuni file, e il server li deve fornire. Ma naturalmente, trattandosi di WordPress, il tutto non viene fatto nel contesto di un server http statico, in cui la compromissione sarebbe difficile: viene fatto in un contesto che comprende molte altre funzionalità. Cito: It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. Non è possibile dedurre molto da questa affermazione, nè mi interessa dare addosso a WordPress in particolare, ma sembra probabilmente il caso in cui dalla compromissione di un contesto si è arrivati a comprometterne un altro. La risposta immediata a un problema di questo tipo sarebbe la segregazione: se manipolare la distribuzione di un pacchetto software ha una criticità diversa rispetto, che so, a pubblicare un post di commento (e ce l’ha), allora i due contesti dovrebbero essere separati, almeno logicamente. La critica è altrettanto immediata: troppi “contesti diversi” sono scomodi e difficili da gestire, finiscono per rallentare il lavoro e nel complesso possono diventare inefficaci perché inutilizzabili in modo corretto. Entrambe le affermazioni sono vere: l’importante è che la scelta dell’una o dell’altra posizione, o di soluzioni di compromesso, sia una scelta consapevole e fatta caso per caso, e non una posizione preconcetta.
Qual’è stata la soluzione di WordPress? We are also taking lots of measures to ensure something like this can’t happen again, not the least of which is minutely external verification of the download package so we’ll know immediately if something goes wrong for any reason. Dove altre misure non sono (o non vogliono essere) praticabili, rimane il monitoraggio…
