Nel repository di pacchetti RubyGems.org è stata identificata una vulnerabilità critica (CVE-2022-29176), che consente, in assenza dei necessari permessi, di sostituire alcuni pacchetti altrui nel repository mediante l'inizio di un'operazione di rimozione (yank) di un pacchetto legittimo e il caricamento al suo posto di un altro file con lo stesso nome e numero di versione.
Per sfruttare con successo la vulnerabilità è necessario che siano soddisfatte tre condizioni:
- L'attacco può essere effettuato solo su pacchetti il cui nome contiene il carattere trattino.
- L'attaccante deve essere in grado di caricare un pacchetto gem con parte del nome prima del trattino. Ad esempio, se l'attacco è diretto al pacchetto "rails-html-sanitizer", l'attaccante deve caricare nel repository il proprio pacchetto "rails-html".
- Il pacchetto bersaglio dell'attacco deve essere stato creato negli ultimi 30 giorni o non essere stato aggiornato negli ultimi 100 giorni.
La vulnerabilità è causata da un errore nel gestore dell'azione "yank", che interpreta la parte del nome dopo il trattino come il nome della piattaforma, permettendo così di avviare la rimozione di pacchetti altrui che coincidono nella parte del nome prima del trattino. In particolare, nel codice del gestore dell'operazione "yank" veniva utilizzata una chiamata 'find_by!(full_name: "#{rubygem.name}-#{slug}")', mentre il parametro "slug" era fornito dal proprietario del pacchetto per determinare la versione da rimuovere. Il proprietario del pacchetto "rails-html" invece di specificare la versione "1.2.3" poteva indicare "sanitizer-1.2.3", il che avrebbe comportato l'applicazione dell'operazione a un pacchetto altrui "rails-html-sanitizer-1.2.3".
Il problema è stato identificato da un ricercatore di sicurezza nell'ambito del programma attivo su HackerOne di ricompense per la segnalazione di problemi di sicurezza in noti progetti open source. La questione è stata risolta in RubyGems.org il 5 maggio e, secondo quanto dichiarato dagli sviluppatori, al momento non sono state trovate tracce di sfruttamento della vulnerabilità nei log degli ultimi 18 mesi. Finora è stata condotta solo una revisione superficiale e si prevede di effettuare un controllo più approfondito in seguito.
Per verificare i propri progetti, è consigliabile analizzare la cronologia delle operazioni nel file Gemfile.lock, l'attività dannosa si esprime con la presenza di modifiche che mantengono il nome e la versione o attraverso il cambiamento della piattaforma (ad esempio, quando il gemname-1.2.3 viene aggiornato a gemname-1.2.3-java). Come metodo alternativo per proteggersi dalla sostituzione occulta dei pacchetti nei sistemi di integrazione continua o durante la pubblicazione dei progetti, è consigliato agli sviluppatori di utilizzare Bundler con le opzioni "—frozen" o "—deployment" per fissare le dipendenze.
Fonte: opennet.ru
