Falla di sicurezza critica: glibc stack-based buffer overflow in getaddrinfo() (CVE-2015-7547)
Il pacchetto glibc contiene alcune librerie standard usate da programmi multipli presenti sul sistema. Per salvaguardare lo spazio sul disco e la memoria, e per facilitare il processo di aggiornamento, il codice comune del sistema è archiviato in una posizione unica e condivisa tra i programmi. Questo pacchetto contiene la libreria C standard, nei confronti della quale tutti i programmi GNU/Linux sono collegati. La libreria libresolv disponibile con glibc, fornisce le funzioni necessarie per la traduzione degli hostname e indirizzi IP. nss_dns è il componente glibc che fornisce il modulo del servizio Name Service Switch (NSS), il quale utilizza libresolv per eseguire le ricerche DNS.
Informazioni supplementari
È stato identificato uno stack-based buffer overflow in libresolv nel codice che esegue le interrogazioni dual A/AAAA DNS. Un utente malizioso remoto è in grado di creare risposte DNS che causano un arresto inaspettato di libresolv, o in grado di eseguire il codice con i permessi dell'utente che esegue la libreria. Il buffer overflow si verifica nella funzione send_dg (per le interrogazioni UDP) e send_vc (per quelle di TCP) in libresolv. Questo problema è evidente durante l'invocazione di libresolv da parte del modulo del servizio NSS nss_dns. A questa falla è stata assegnata CVE-2015-7547.
Sono interessate a questa vulnerabilità le applicazioni che invocano getaddrinfo utilizzando una famiglia di indirizzi AF_UNSPEC. Fa eccezione Red Hat Enterprise Linux 6.4, dove le applicazioni sono interessate anche se utilizzano la famiglia di indirizzi AF_INET6. Le applicazioni che utilizzano solo funzioni più vecchie di gethostbyname, o funzioni libresolv come res_search (e non getaddrinfo), non sono interessate.
Questo problema non interessa le versioni di glibc disponibili con Red Hat Enterprise Linux 5 o versioni precedenti, ma interessa le versioni di glibc disponibili con Red Hat Enterprise Linux 6 e 7.
Impatto
Questa vulnerabilità è stata classificata da Red Hat Product Security come Critical.
Come attenuare i rischi
In una configurazione predefinita di libresolv, è possibile mitigare il vettore basato su UDP implementando un resolver DNS fidato conforme al protocollo con una rete fidata. Un resolver conforme non genererà risposte molto grandi utilizzabili per sfruttare questo tipo di vulnerabilità poichè, per impostazione predefinita, il resolver glibc non abilita EDNS0 e non richiede risposte molto grandi.
Il vettore basato su TCP può essere mitigato da un resolver ricorsivo fidato su una rete fidata che limita la dimensione delle singole risposte DNS a 1023 byte, o una dimensione minore. Tuttavia questa capacità non è comune nelle implementazioni del resolver DNS, poichè impatta negativamente sul protocollo DNS. (L'opzione di configurazione per la dimensione del buffer offerta da numerosi resolver è valida solo per UDP e non TCP.) Il rifiuto delle risposte AAAA, senza limitare la dimensione delle risposte A, non è sufficiente per mitigare questo tipo di vulnerabilità.
La disabilitazione del supporto IPv6 sui sistemi interessati non mitiga la vulnerabilità poichè le dual A/AAAA lookup vengono eseguite se il sistema è sprovvisto di supporto IPv6.
Prodotti interessati e risoluzione
Tutte le versioni del pacchetto glibc incluse con Red Hat Enterprise Linux 6 e 7 sono interessate da questo tipo di vulnerabilità. Consultare la tabella di seguito indicata per i security advisory idonei a risolvere questo tipo di problema:
Risoluzione
Prodotto | Advisory |
---|---|
Red Hat Enterprise Linux 6 | RHSA-2016:0175 |
Red Hat Enterprise Linux 7 | RHSA-2016:0176 |
Red Hat Enterprise Linux 6.2 Advanced Update Support | RHSA-2016:0225 |
Red Hat Enterprise Linux 6.4 Advanced Update Support | RHSA-2016:0225 |
Red Hat Enterprise Linux 6.5 Advanced Update Support | RHSA-2016:0225 |
Red Hat Enterprise Linux 6.6 Extended Update Support | RHSA-2016:0225 |
Red Hat Enterprise Linux 7.1 Extended Update Support | RHSA-2016:0225 |
Dopo aver applicato l'aggiornamento è necessario riavviare il sistema o tutti i servizi interessati:
Poichè questa vulnerabilità interessa un numero molto elevato di applicazioni presenti sul sistema, il metodo più sicuro per assicurarsi che ogni applicazione utilizzi i pacchetti glibc è quello di riavviare il sistema.
Se dopo aver implementato gli aggiornamenti non è possibile riavviare l'intero sistema, eseguire il seguente comando per elencare tutti i processi in esecuzione (non limitato ai soli servizi) che utilizzano ancora la vecchia versione [in-memoria] di glibc sul sistema.
lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t
Dall'elenco risultante identificare i servizi disponibili al pubblico e riavviarli. Anche se questo processo offre una soluzione temporanea, questo tipo di approccio non è supportato da Red Hat e, in presenza di errori, potrà essere richiesto all'utente di riavviare il sistema prima di iniziare il processo di troubleshooting.
FAQ
1. SELinux è in grado di risolvere questa falla di sicurezza?
Una politica corretta di SELinux è in grado di limitare i danni apportati da un utente malizioso e limitarne il suo accesso al sistema. Poichè DNS viene utilizzato da numerose applicazioni e componenti, le politiche di SELinux offrono solo una soluzione limitata a questo tipo di problema.
2. Può un resolver DNS fidato proteggerci da questo problema?
Un resolver fidato, in una configurazione predefinita conforme al protocollo, non è in grado di mitigare questo tipo di problema poichè con questa vulnerabilità è possibile utilizzare risposte DNS con una sintassi corretta.
3. Questa vulnerabilità interessa anche i binari collegati staticamente?
Red Hat non supporta il collegamento statico di glibc. Tuttavia se gli utenti dispongono di applicazioni collegate staticamente usando il pacchetto glibc-static
, queste applicazioni continueranno a utilizzare le copie del sistema nss_dns e libresolv, e l'installazione di pacchetti glibc aggiornati risolverà questo tipo di vulnerabilità.
Riconoscimenti
Questa vulnerabilità è stata scoperta dal Google Security Team e Red Hat.
Comments