C’è un che di antico, di quasi romantico, nell’idea di sigillare qualcosa con la ceralacca. Un gesto definitivo, una promessa di integrità che sopravvive al tempo. Ebbene, questa metafora così fisica e rassicurante è approdata nel mondo etereo e volatile della memoria dei processi Linux.
Con il kernel 6.10, il pinguino ha imparato un nuovo trucco: il sistem call mseal(). Il nome è tutto un programma. Permette a un processo di “sigillare” una regione della sua memoria, rendendola di fatto immutabile nelle sue proprietà fondamentali. Dopo quella chiamata, nessuno – nemmeno il processo stesso – potrà più cambiarne i permessi, spostarla, reindirizzarla con mremap, ridurne le dimensioni o liberarla prematuramente.
Non si tratta di renderla read-only a livello di permessi, operazione banale e comunque bypassabile. È una protezione più profonda, a livello del kernel stesso, che congella la “forma” della mappatura di memoria. È come se, dopo aver sistemato tutti i mobili nella stanza, si potesse sigillare la porta. I mobili stessi potrebbero forse ancora essere spostati (se i permessi lo consentono), ma la stanza non potrà più essere ingrandita, rimpicciolita, demolita o trasformata in un ripostiglio.
L’obiettivo è chiaro e nobile: blindare quelle strutture dati critiche che, se manipolate da un attaccante che ha ottenuto un primissimo appiglio nel processo, potrebbero essere usate per eseguire codice arbitrario o alterare il flusso del programma in modo catastrofico. Pensa ai mitigator contro gli attacchi JIT-ROP, dove la riallocazione di pagine di memoria è un vettore comune. Sigillando le pagine che contengono codice critico o strutture di controllo, si alza di molto l’asticella per l’avversario.
Ma un sistem call, da solo, è un’arma spuntata per la maggior parte degli sviluppatori. È come avere una formula chimica segreta per un super-adesivo: potente, ma scomoda da usare senza un applicatore. Ed è qui che entra in scena Glibc, l’umile e onnipresente libreria C, che fa da ponte tra il mondo degli umani e quello del kernel.
La prossima release, la Glibc 2.43 attesa per febbraio, integrerà un wrapper per mseal(). Un gesto semplice, quasi ovvio, che però democratizza questa potentissima funzionalità. D’un tratto, non servirà più invocare direttamente il sistem call con la sua arcaica danza di parametri; basterà una semplice chiamata di funzione. È questo il passaggio che trasforma una curiosità del kernel in uno strumento a disposizione di ogni programma linkato dinamicamente con Glibc.
L’implementazione, per ora, è disponibile per le architetture x86_64 e AArch64, le due colonne portanti del computing moderno. Non è una panacea, ovviamente. Il codice dovrà essere progettato con cura, sigillando la memoria solo dopo che ha finito di configurarla, altrimenti si rischia di auto-imbavagliarsi. Ma per le librerie di sicurezza, i runtime più esposti o anche solo per quei moduli di un’applicazione che gestiscono segreti o meccanismi di autenticazione, mseal offre un’arma in più in una guerra difensiva che si combatte sempre più a livello di memoria.
La diffusione sarà rapida. Glibc è il cuore pulsante di quasi ogni distribuzione Linux. Quando la 2.43 troverà la sua strada in Fedora, Ubuntu, Debian e compagnia bella, mseal sarà lì, a disposizione di chi vuole costruire software un po’ più robusto, un po’ più resistente alle intemperie del mondo digitale. Un piccolo sigillo di ceralacca, nell’universo fatto di bit.