recentemente sono state rilasciate informazioni sulle vulnerabilità che sono stati trovati nelle librerie standard delle lingue arrugginisci e vai, quali sono relativi alla cattiva gestione degli indirizzi IP con cifre ottali nelle funzioni di analisi degli indirizzi.
Si dice che eQueste vulnerabilità consentono di evitare verifiche di indirizzi validi en applicazioni, ad esempio, per organizzare l'accesso agli indirizzi dell'interfaccia di loopback o alle sottoreti intranet quando vengono eseguiti attacchi di spoofing delle richieste lato server.
Le vulnerabilità in queste due lingue Le stringhe di indirizzi IP hanno una realizzazione nella specifica in base zero, visto che sei in teoria dovrebbero essere interpretati come numeri ottali, ma il problema che causa questi problemi è che molte librerie lo ignorano e scartano semplicemente lo zero, quindi finiscono per trattare il valore come un numero decimale.
Ad esempio, per capire come vengono interpretati gli indirizzi IP in questi bug, il numero 0177 in ottale è 127 in decimale e con il quale un attaccante può richiedere una risorsa specificando il valore "0177.0.0.1", che, non essendo preso come ottale, la notazione decimale per questo è "127.0.0.1".
Ecco perché in caso di utilizzo di una delle librerie problematiche, l'applicazione non rileverà l'occorrenza dell'indirizzo 0177.0.0.1 nella sottorete 127.0.0.1, ma in effetti, quando si invia una richiesta, è possibile chiamare l'indirizzo "0177.0.0.1" che a causa di un'interpretazione errata, le funzioni di rete lo elaboreranno come 127.0.0.1. Allo stesso modo, l'accesso agli indirizzi intranet può essere ingannato e verificato specificando vari valori, che l'attaccante valuterà per un possibile sfruttamento.
Dalla parte di Rust, è stato riscontrato che il problema è soggetto alla libreria standard "std :: net" e che è già catalogato sotto "CVE-2021-29922". Descrive che il parser dell'indirizzo IP di questa libreria scarta uno zero davanti ai valori dell'indirizzo, ma solo se sono state specificate non più di tre cifre, ad esempio "0177.0.0.1" verrà interpretato come un valore non valido e in risposta verrà restituito un risultato errato.
La convalida errata dell'input della stringa ottale nella libreria "net" standard di rust-lang consente agli aggressori remoti non autenticati di eseguire attacchi SSRF, RFI e LFI indeterminati su molti programmi che dipendono da rust-lang std :: net. Gli ottetti dell'indirizzo IP vengono eliminati invece di essere valutati come indirizzi IP validi.
Viene anche menzionato che le applicazioni che utilizzano la libreria std :: net :: IpAddr durante l'analisi di indirizzi specificati dall'utente sono potenzialmente suscettibili agli attacchi SSRF (spoofing della richiesta lato server), RFI (inclusione di file remoti) e LFI (inclusione di file locali). Allo stesso modo, un utente malintenzionato può inserire 127.0.026.1, che in realtà è 127.0.22
Ad esempio, un utente malintenzionato che invia un indirizzo IP a un'applicazione Web basata su std :: net :: IpAddr potrebbe causare SSRF inserendo dati di input ottali; Un utente malintenzionato può inviare indirizzi IP sfruttabili se l'ottetto ha 3 cifre, con l'ottetto minimo sfruttabile 08 che porta al denial of service e l'ottetto massimo sfruttabile 099 che porta anche al denial of service.
Se vuoi saperne di più su questa vulnerabilità in Rust, puoi controllare i dettagli nel seguente link Viene anche menzionato che la vulnerabilità è stata risolta nel ramo Rust 1.53.0.
Appena al problema che colpisce to Go, si dice che questo è soggetto alla libreria standard «net» ed è già elencato sotto CVE-2021-29923. Nella descrizione si dice che consente agli aggressori remoti non autenticati di eseguire attacchi SSRF, RFI e LFI indeterminato in molti programmi che dipendono dalla funzione net.ParseCIDR incorporata di golang. I singoli ottetti IP CIDR vengono rimossi invece di valutarli come ottetti IP validi.
Ad esempio, un utente malintenzionato potrebbe passare il valore 00000177.0.0.1, che, se verificato nella funzione net.ParseCIDR, verrà analizzato come 177.0.0.1/24, non 127.0.0.1/24. Il problema si manifesta anche sulla piattaforma Kubernetes. La vulnerabilità è stata risolta nella versione Go 1.16.3 e nella versione beta 1.17.
Puoi saperne di più su questa vulnerabilità nel seguente link