Nel digest di questa settimana discuteremo di:
- un avviso di sicurezza della versione 3.0.0 di OpenSSL;
- una vulnerabilità di overflow dei limiti degli array di Sqlite; e
- un attacco di repojacking su GitHub.
Avviso di sicurezza Openssl
OpenSSL 3.0.0 ha recentemente risolto due vulnerabilità: CVE-2022-3602 e CVE-2022-3786.
La CVE-2022-3602, classificata come critica (9,8/10), comporta un overflow del buffer di stack a 4 byte che può portare a DoS o all'esecuzione di codice. Per uno sfruttamento efficace, l'obiettivo deve eseguire la convalida del certificato X509 di un certificato dannoso, in particolare il controllo dei vincoli del nome. Un aggressore può creare un indirizzo e-mail dannoso per far andare in overflow quattro byte controllati dall'aggressore sullo stack. Detto questo, l'attacco potrebbe essere vanificato dalle protezioni contro l'overflow dello stack tipicamente attivate nei sistemi operativi moderni. La vulnerabilità è stata inizialmente descritta come critica da OpenSSL, ma ulteriori analisi hanno portato a declassare la gravità ad alta. Al momento in cui scriviamo, il punteggio di base è 9,8 (critico).
CVE-2022-3786, con una valutazione alta (7,5/10), è un altro buffer overflow che viene innescato da un certificato tls dannoso. Simile alla vulnerabilità precedente, l'attacco comporta la creazione da parte di un aggressore di un certificato con un indirizzo e-mail dannoso. La differenza sta nei caratteri che possono essere utilizzati per causare un overflow, che è limitato al carattere `.' (decimale 46), che porta al blocco del servizio o al Denial of Service.
Gli utenti che utilizzano OpenSSL 3.0 sono invitati ad aggiornare alla versione più recente il prima possibile. Questo post del blog potrebbe essere utile per aiutare gli utenti a determinare se la versione vulnerabile della libreria è in uso nei loro ambienti.
Vulnerabilità di overflow dei limiti di array di Sqlite
TrailofBits ha rivelato una vulnerabilità ad alta gravità in una popolare libreria DBMS Sqlite recentemente patchata Il CVE assegnato a questa vulnerabilità è CVE-2022-35737 ed è valutato 7,5/10.
La vulnerabilità è un array overflow in SQLite 1.0.12 fino a 3.39.x prima di 3.39.2 e colpisce le applicazioni che utilizzano la libreria SQLite. API. La sfruttabilità dipende dal modo in cui SQLite viene compilato; se il programma viene compilato senza i canarini dello stack abilitati, è possibile l'esecuzione di codice. La vulnerabilità è stata introdotta nella versione 1.0.12, rilasciata il 17 ottobre 2000.
Secondo la fonte, "Sui sistemi vulnerabili, CVE-2022-35737 è sfruttabile quando vengono passati input di stringa di grandi dimensioni alle implementazioni SQLite delle funzioni printf e quando la stringa di formato contiene i tipi di sostituzione di formato %Q, %q o %w". Questo riduce la superficie di attacco e la probabilità che un'applicazione sia effettivamente sfruttabile attraverso questa vulnerabilità, anche se si raccomanda agli utenti di valutare il rischio nel contesto dell'uso del componente.
La versione di SQLite v3.39.2 con patch è disponibile per l'aggiornamento nelle applicazioni degli utenti. Gli utenti che dipendono da strumenti che utilizzano la libreria SQLite vulnerabile dovranno attendere il rilascio della patch da parte dei manutentori del codice. Trailofbits ha anche rilasciato il POC dell'exploit, disponibile su GitHub.
Github Repojacking
Checkmarx ha rivelato un altro metodo per attaccare la catena di approvvigionamento prendendo di mira i repository di codice ospitati su github.com. L'attacco è denominato repojacking e prevede l'acquisizione di un repository aggirando un controllo di sicurezza preesistente impostato da Microsoft per questo tipo di attacchi. Questo controllo è denominato "popular-repository-namespace-retirement" e sostanzialmente impedisce agli utenti di GitHub di creare repository con un nome che corrisponde a quello precedentemente utilizzato da un utente disattivato con lo stesso nome utente se il repository ha avuto più di 100 cloni nella settimana precedente al cambio di nome utente. È stata implementata come mitigazione da GitHub dopo che checkmarx aveva rivelato una vulnerabilità simile nel 2021.
Il nuovo attacco aggira la mitigazione sfruttando una funzione di Github chiamata trasferimento di repository. Ecco come viene portato avanti l'attacco:
- "victim/repo" è un repository GitHub popolare ritirato sotto la protezione "popular repository namespace retirement".
- "helper_account" crea il repository "repo".
- "helper_account" trasferisce la proprietà del repository "repo" a "attacker_account".
- "account_attaccante" rinomina il suo nome utente in "vittima".
- Il nuovo account "vittima" (in precedenza "account_attaccante") accetta il trasferimento di proprietà e assume essenzialmente il controllo del repository di destinazione.
La correzione per questa vulnerabilità è stata applicata. Checkmarx ha anche rilasciato uno strumento per verificare quali dipendenze dirette di Golang potrebbero essere vulnerabili a questo tipo di attacco.
Commenti