Diverse settimane fa, la comunità Linux è stata scossa dal notizie inquietanti che i ricercatori dell’Università del Minnesota avevano sviluppato (ma, come si è scoperto, non eseguito completamente) un metodo per introdurre quelli che chiamavano “commit ipocriti” nel kernel di Linux – l’idea era quella di distribuire comportamenti difficili da rilevare, privi di significato in sé , che in seguito potrebbe essere allineato dagli aggressori per manifestare vulnerabilità.

Questo è stato rapidamente seguito dall’annuncio, per certi versi altrettanto inquietante, che all’università era stato vietato, almeno temporaneamente, di contribuire allo sviluppo del kernel. UN scuse pubbliche dai ricercatori seguiti.

Sebbene lo sviluppo e la divulgazione degli exploit siano spesso disordinati, l’esecuzione di programmi “red team” tecnicamente complessi contro il più grande e importante progetto open source del mondo sembra un po’ in più. È difficile immaginare ricercatori e istituzioni così ingenui o derelitti da non comprendere il raggio di esplosione potenzialmente enorme di tale comportamento.

Altrettanto certo, i manutentori e la governance del progetto hanno il dovere di applicare la politica ed evitare di perdere tempo. Il buon senso suggerisce (e gli utenti chiedono) che si sforzano di produrre versioni del kernel che non contengano exploit. Ma uccidere il messaggero sembra perdere almeno parte del punto: che si trattava di ricerca piuttosto che di pura malizia, e che mette in luce una sorta di vulnerabilità del software (e organizzativa) che richiede una mitigazione tecnica e sistemica.

I progetti della portata e dell’assoluta criticità del kernel Linux non sono preparati a fare i conti con modelli di minacce iperscalabili e rivoluzionari.

Penso che il contrattempo degli “impegni ipocriti” sia sintomatico, da ogni parte, di tendenze correlate che minacciano l’intero ecosistema open source esteso e i suoi utenti. Quell’ecosistema ha lottato a lungo con problemi di scala, complessità e importanza sempre più critica del software libero e open source (FOSS) per ogni tipo di impresa umana. Diamo un’occhiata a quel complesso di problemi:

  • I più grandi progetti open source ora presentano grandi obiettivi.
  • La loro complessità e il loro ritmo sono cresciuti oltre la scala in cui possono far fronte i tradizionali approcci di “beni comuni” o modelli di governance ancora più evoluti.
  • Si stanno evolvendo per mercificarsi a vicenda. Ad esempio, sta diventando sempre più difficile stabilire in modo categorico se “Linux” o “Kubernetes” debbano essere trattati come il “sistema operativo” per le applicazioni distribuite. Le organizzazioni a scopo di lucro ne hanno preso atto e hanno iniziato a riorganizzarsi attorno a portafogli e narrazioni “full-stack”.
  • In tal modo, alcune organizzazioni a scopo di lucro hanno iniziato a distorcere i modelli tradizionali di partecipazione FOSS. Sono in corso molti esperimenti. Nel frattempo, i finanziamenti, gli impegni di personale per FOSS e altri parametri sembrano in declino.
  • I progetti e gli ecosistemi OSS si stanno adattando in modi diversi, a volte rendendo difficile per le organizzazioni a scopo di lucro sentirsi a casa o vedere benefici dalla partecipazione.

Nel frattempo, il panorama delle minacce continua a evolversi:

  • Gli aggressori sono più grandi, più intelligenti, più veloci e più pazienti, portando a lunghi giochi, sovversione della catena di approvvigionamento e così via.
  • Gli attacchi sono più redditizi che mai dal punto di vista finanziario, economico e politico.
  • Gli utenti sono più vulnerabili, esposti a più vettori che mai.
  • L’uso crescente di cloud pubblici crea nuovi livelli di monoculture tecniche e organizzative che possono consentire e giustificare gli attacchi.
  • Le complesse soluzioni commerciali pronte all’uso (COTS) assemblate parzialmente o interamente da software open source creano elaborate superfici di attacco i cui componenti (e interazioni) sono accessibili e ben compresi dai malintenzionati.
  • La componentizzazione del software consente nuovi tipi di attacchi alla catena di approvvigionamento.
  • Nel frattempo, tutto questo sta accadendo mentre le organizzazioni cercano di liberarsi delle competenze non strategiche, spostare le spese in conto capitale in spese operative ed evolversi per dipendere dai fornitori di cloud e da altre entità per svolgere il duro lavoro della sicurezza.

Il risultato netto è che i progetti della scala e dell’assoluta criticità del kernel Linux non sono preparati a fare i conti con modelli di minaccia iperscala e rivoluzionari. Nel caso specifico che stiamo esaminando qui, i ricercatori sono stati in grado di mirare ai siti di incursione candidati con uno sforzo relativamente basso (utilizzando strumenti di analisi statica per valutare unità di codice già identificate come richiedenti l’attenzione del contributore), proporre “correzioni” informalmente via e-mail e sfruttare molti fattori, inclusa la propria reputazione consolidata come contributori affidabili e frequenti, per portare il codice di exploit sull’orlo dell’essere commesso.

Questo è stato un grave tradimento, effettivamente da parte degli “addetti ai lavori” di un sistema di fiducia che storicamente ha funzionato molto bene per produrre versioni del kernel robuste e sicure. L’abuso di fiducia stesso cambia il gioco e l’implicito requisito successivo – per rafforzare la fiducia umana reciproca con mitigazioni sistematiche – incombe.

Ma come si fa a combattere minacce come questa? La verifica formale è effettivamente impossibile nella maggior parte dei casi. L’analisi statica potrebbe non rivelare incursioni abilmente progettate. I ritmi del progetto devono essere mantenuti (ci sono bug noti da correggere, dopo tutto). E la minaccia è asimmetrica: come dice la linea classica, la squadra blu deve proteggersi da tutto, la squadra rossa deve avere successo solo una volta.

Vedo alcune opportunità di rimedio:

  • Limitare la diffusione delle monocolture. Cose come Alva Linux e la distribuzione aperta di ElasticSearch di AWS sono buone, in parte perché mantengono libere e open source le soluzioni FOSS ampiamente utilizzate, ma anche perché iniettano diversità tecnica.
  • Rivalutare la governance, l’organizzazione e il finanziamento del progetto con l’obiettivo di mitigare la completa dipendenza dal fattore umano, nonché incentivare le aziende a scopo di lucro a contribuire con le proprie competenze e altre risorse. La maggior parte delle aziende a scopo di lucro sarebbe felice di contribuire all’open source a causa della sua apertura, e non nonostante ciò, ma all’interno di molte comunità, ciò potrebbe richiedere un cambiamento culturale per i contributori esistenti.
  • Accelera la mercificazione semplificando lo stack e verificando i componenti. Spingere la responsabilità appropriata per la sicurezza nei livelli dell’applicazione.

Fondamentalmente, quello che sto sostenendo qui è che gli orchestratori come Kubernetes dovrebbero avere meno importanza e Linux dovrebbe avere un impatto minore. Infine, dovremmo procedere il più velocemente possibile verso la formalizzazione dell’uso di cose come gli unikernel.

Indipendentemente da ciò, dobbiamo garantire che sia le aziende che gli individui forniscano le risorse di cui l’open source ha bisogno per continuare.

Source link