Nel leggere le varie pubblicazioni a proposito delle ultime due grandi falle scoperte in Linux, stiamo parlando ovviamente di Copy Fail, scoperto due settimane fa e di Dirty Frag, scoperto questa settimana, tutti giungono ad una conclusione decisamente condivisibile: è più che probabile che questa sia solo la punta dell’iceberg.

Infatti entrambe le vulnerabilità sono frutto di analisi fatte mediante intelligenza artificiale, vero campo di battaglia in cui questi tool possono fare la differenza, ed è più che probabile che exploit di questo tipo verranno scoperti con sempre più frequenza.

Il paradigma di Torvalds, Given enough eyeballs, all bugs are shallow (Con sufficienti occhi, tutti i bug emergono), vale ancora di più per le intelligenze artificiali. Esse non hanno occhi, ma accesso ad una sterminata base di codice e pattern malevoli che ad esso si applicano. Questo significa che, in mani competenti, possono produrre l’identificazione di un problema, la produzione di un exploit che lo sfrutti e, infine, la patch che lo risolve.

Questo spike di identificazioni che stiamo avvertendo, come dicevamo in apertura, è figlio di questo nuovo approccio tecnologico e durerà ancora per diverso tempo, verosimilmente fin quando le pipeline di promozione del codice non avranno tutte integrato gli stessi strumenti che rilevano queste anomalie.

Quel momento, che potremmo definire AI Shift Left, non è così lontano nel tempo, ma intanto la gente si preoccupa e cerca soluzioni nell’immediato.

Una proposta promossa da Sasha Levin (che avevamo già conosciuto per via di AUTOSEL, il maintainer IA del Kernel Linux) ed apparsa in un recente post sulla mailing list del Kernel prevede l’introduzione di un Killswitch, un corto circuito o bottone rosso di spegnimento, che mitighi immediatamente le esposizioni di determinate funzioni (quelle soggette ai problemi come Copy Fail o Dirty Frag), andando a disabilitarle.

Come afferma l’autore:

For most users, the cost of "this socket family stops working for the day" is much smaller than the cost of running a known vulnerable kernel until the fix land.

Per molti utenti il costo di “questa famiglia di socket non lavora più per oggi” è molto minore rispetto al costo di lavorare con un Kernel conosciuto come vulnerabile fino a che non arrivi la sua sistemazione.

Ed in effetti il ragionamento non fa una piega. Sulla carta.

Già, perché se è vero che il bottone rosso preserva eventuali tentativi di violazione ha anche un effetto generale sul funzionamento del sistema. Come spiega Linuxiac, la patch non include controlli di sicurezza automatici per determinare se una funzione può essere disabilitata in modo sicuro. Disabilitare la funzione sbagliata o restituire un valore errato potrebbe compromettere il comportamento del sistema o causare nuovi problemi.

Insomma, siamo lontani dalle mitigazioni dei vari Spectre, Heartbleed e simili, qui si tratta di funzioni proprie del Kernel, non di determinati tipi di iterazione con la CPU che possono essere disabilitati.

Quale soluzione quindi? Bella domanda. Foss Force ha parlato del progetto di uno sviluppatore Debian che ha creato un pacchetto che disabilita le funzionalità incriminate in maniera automatica. Anche qui una sorta di bottone rosso, stavolta mediante pacchetto, permette di selezionare da quali CVE ci si vuole proteggere:

Ma questa soluzione, al netto di non essere considerata ufficiale da Debian, ha evidenti limiti di manutenibilità nel tempo, oltre che di approccio: se una cosa è chiara a tutti è che installare pacchetti a caso sui propri sistemi non è mai una cosa intelligente.

La conclusione quindi, è sempre la stessa: impostare dei cicli di aggiornamento serrati per i propri sistemi e monitorare le fonti ufficiali della propria distribuzione Linux per capire se ci sono novità.

La sicurezza totale è impossibile, ma una rapida capacità di reazione deve essere un obiettivo primario in questo mondo insicuro.