In questo articolo Indice dei contenuti 2 sezioni
Una vulnerabilità critica in GitLab permette potenzialmente a un aggressore remoto di eseguire codice arbitrario sul server senza nemmeno doversi autenticare. Il difetto ha ricevuto un punteggio CVSS di 10 su 10, il massimo possibile, e coinvolge sia GitLab Community Edition (CE) sia Enterprise Edition (EE). A colpire è soprattutto l’età del problema, visto che riguarda anche versioni distribuite oltre 12 anni fa. Il bug risale almeno a GitLab 7.0, uscito nel 2014, e si annida in un componente che il software usa per elaborare le espressioni regolari.
Il 21 ottobre GitLab ha pubblicato un aggiornamento straordinario che corregge la falla in 7 diversi rami del prodotto, con un invito esplicito agli amministratori delle installazioni gestite in proprio a intervenire subito. La patch arriva appena 9 giorni dopo un’altra correzione di sicurezza dedicata a una vulnerabilità molto simile, anche quella valutata con il punteggio più alto della scala.
La gravità nasce dall’incrocio di tre fattori. C’è l’accesso da remoto, c’è l’assenza di qualsiasi credenziale richiesta e c’è la possibilità di compromettere un server che spesso custodisce codice sorgente, credenziali tecniche e informazioni usate nei processi di sviluppo e distribuzione del software. GitLab precisa comunque che lo sfruttamento richiede determinate condizioni, senza averne ancora reso noti i dettagli.
Perché la falla nelle espressioni regolari è così pericolosa
All’origine di tutto c’è un errore di tipo integer overflow che si manifesta durante la compilazione di una particolare espressione regolare. Nel bollettino ufficiale del 21 ottobre l’azienda conferma che un utente non autenticato potrebbe, in certe circostanze, ottenere l’esecuzione di codice da remoto (RCE) sul server che ospita l’applicazione.
Il punto debole si trova proprio nel compilatore delle espressioni regolari. Un’espressione costruita ad arte può spingere il sistema lungo percorsi di elaborazione che quelle ordinarie non toccano mai. Se uno dei calcoli supera i limiti previsti e il programma non gestisce correttamente il risultato, il processo può finire in uno stato inatteso.
Per capire come mai versioni tanto lontane tra loro siano tutte coinvolte bisogna guardare a uno dei mattoni su cui poggia la piattaforma. GitLab fa largo uso di Ruby, linguaggio che offre un motore nativo per gestire le espressioni regolari chiamato Onigmo. Questo motore contiene codice nativo che interpreta, compila ed esegue le espressioni, quindi una debolezza nella gestione della memoria o nei calcoli interni può avere conseguenze ben diverse rispetto a un normale errore gestito dal runtime Ruby.
È l’ennesima dimostrazione di come le dipendenze software possano nascondere difetti capaci di sopravvivere per anni, anche quando l’applicazione che le usa riceve aggiornamenti frequenti. E se il problema emerge in una libreria integrata così in profondità, sistemarlo significa mettere mano a numerose versioni del prodotto.
Quali versioni di GitLab aggiornare e come verificare l’esposizione
Data la criticità, l’azienda ha distribuito la correzione anche su rami che di norma non rientrerebbero nella sua politica di manutenzione. Le release correttive sono GitLab 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1. Chi usa GitLab 19.5 deve passare almeno alla 19.5.1, per il ramo 19.4 la prima versione sicura è la 19.4.3 e per il 19.3 è la 19.3.6. Chi mantiene installazioni 19.2, 19.1 e 19.0 deve adottare rispettivamente la 19.2.9, la 19.1.9 e la 19.0.10, mentre la correzione è disponibile anche nella 18.11.13.
Tutte le versioni di GitLab dalla 7.0 precedenti alla 18.11.13 rientrano nell’intervallo vulnerabile. La manutenzione ordinaria copre normalmente la versione mensile corrente e le due precedenti, ma in questo caso il produttore ha fatto il backport della patch anche sui rami 18.11, 19.0, 19.1 e 19.2.
Il primo passo è capire con esattezza quale versione di GitLab sia in esecuzione. Gli amministratori possono ricavarla dalle informazioni dell’istanza oppure dagli strumenti presenti sul server, a seconda del metodo di installazione. Nelle installazioni basate sui pacchetti Linux un apposito comando rake di GitLab restituisce i dati sull’ambiente, versione compresa. Nei deployment containerizzati o su Kubernetes bisogna invece controllare anche il tag dell’immagine effettivamente distribuita.
Un’istanza raggiungibile pubblicamente offre ovviamente una superficie di attacco diversa rispetto a un sistema accessibile solo da una rete privata. Anche una rete interna però può ospitare dispositivi compromessi o utenti non affidabili, e limitare l’accesso riduce l’esposizione senza correggere il difetto.
Fonte: TecnoAndroid