Questa settimana tratteremo un paio di vulnerabilità ad alta gravità, una in Rubygems e un'altra in Rsyslogs. Parleremo anche dell'importanza di definire pratiche di codifica sicure.
Acquisizione non autorizzata di gemme in Rubygems
Rubygems è un registro di pacchetti utilizzato per fornire software per l'ecosistema del linguaggio Ruby. A causa di un bug nell'azione yank, era possibile per qualsiasi utente di RubyGems.org rimuovere e sostituire alcune gemme anche se non era autorizzato a farlo.
Per essere vulnerabili, occorreva una gemma:
- Uno o più trattini nel nome
- Una gemma controllata dall'attaccante con il nome prima del trattino
- Creazione entro 30 giorni OPPURE nessun aggiornamento per oltre 100 giorni
Mitigazione
Secondo il team di Bundler, l'uso di Bundler in modalità -frozen o -deployment nell'integrazione continua e durante le distribuzioni garantirà che l'applicazione non passi silenziosamente alle versioni create con questo exploit.
Per verificare la cronologia dell'applicazione alla ricerca di possibili exploit passati, esaminare Gemfile.lock e cercare le gemme la cui piattaforma è cambiata mentre il numero di versione non è cambiato. Ad esempio, l'aggiornamento di gemname-3.1.2 a gemname-3.1.2-java potrebbe indicare un possibile abuso di questa vulnerabilità. RubyGems.org è stato patchato e non è più vulnerabile a questo problema.
Potenziale overflow del buffer basato su heap in Rsyslog
Rsyslog è un sistema veloce come un razzo per l'elaborazione dei log. Alcuni moduli per la ricezione TCP di syslog presentano un overflow del buffer heap quando viene utilizzato il framing con conteggio degli ottetti. Nel framing "octet-counted", ogni messaggio è preceduto dalla lunghezza effettiva del messaggio, in modo che il destinatario sappia esattamente dove finisce il messaggio. L'aggressore può corrompere i valori dell'heap, con conseguenti problemi di integrità dei dati e impatto sulla disponibilità. L'esecuzione di codice remoto è improbabile ma non impossibile. Le versioni 8.2204.0 e inferiori sono affette da questa vulnerabilità.
Mitigazione
Il framing con conteggio degli ottetti non è molto comune. Di solito, deve essere abilitato specificamente dai mittenti. Se gli utenti non ne hanno bisogno, possono disattivarlo per i moduli più importanti. In questo modo si attenua la vulnerabilità. Il modo in cui farlo dipende dal modulo. Fare riferimento qui per i moduli interessati e i dettagli di configurazione in base ai moduli. La patch è disponibile nella versione 8.2204.1.
L'importanza di definire un codice sicuro
La codifica sicura è la pratica degli sviluppatori esperti di scrivere codice privo di vulnerabilità fin dall'inizio del ciclo di vita dello sviluppo del software (SDLC). Solo una volta definita questa pratica, la comunità degli sviluppatori può lavorare per raggiungere questo obiettivo. Secure Code Warrior ha condotto il sondaggio The state of developer-driven security, 2022 in collaborazione con Evans Data Corp nel dicembre 2021, intervistando 1.200 sviluppatori a livello globale per comprendere le competenze, le percezioni e i comportamenti in merito alle pratiche di codifica sicura, nonché il loro impatto e la loro rilevanza percepita nell'SDLC.
Ecco alcuni punti salienti dell'indagine:
- Su 1.200 sviluppatori di software attivi, solo il 14% ha come priorità assoluta la sicurezza della codifica.
- Il 37% degli sviluppatori intervistati ha dichiarato di aver lasciato vulnerabilità note all'interno del proprio codice perché le scadenze strette non consentivano il tempo necessario per risolverle o per codificare correttamente fin dall'inizio.
- Il 36% degli intervistati ha inoltre dichiarato di voler eliminare le vulnerabilità dal proprio codice, ma di non avere le competenze o le conoscenze per farlo.
- In molti casi, il problema per gli sviluppatori di scrivere codice sicuro è che le organizzazioni per cui lavorano non hanno identificato le migliori pratiche necessarie per produrre codice sicuro e non hanno investito risorse sufficienti per formare o mettere in grado i loro sviluppatori di raggiungere tali obiettivi.
Quindi, oltre a definire correttamente le pratiche di codifica sicura, le organizzazioni devono anche prevedere scadenze più lunghe per dare agli sviluppatori il tempo necessario per codificare correttamente e fornire una formazione pratica che li aiuti a identificare e correggere le vulnerabilità del codice in modo efficiente.
Per maggiori informazioni sull'indagine, consultare il sito.
Commenti