Il team di sicurezza di Google torna a colpire: gli ingegneri di Mountain View hanno trovato sette nuove problematiche di sicurezza relative, questa volta, al noto software DNSmasq .
La prima di queste è la CVE-2017-13704, nota già dai primi di settembre; le altre sei – di più recente scoperta – sono state numerate nel database CVE in modo progressivo, da CVE-2017-14491 a CVE-2017-14496. Tutte presentano un impatto elevato .
Oltre ad aver divulgato le informazioni a proposito di tali problematiche, gli esperti di Google hanno realizzato anche alcune proof-of-concept .
Per comprendere la gravità delle vulnerabilità è necessario innanzitutto conoscere DNSmasq .
DNSmasq è una soluzione molto popolare negli ambienti Linux, BSD e OSX che, come facilmente intuibile dal nome, implementa il protocollo DNS ( Domain Name System ), ovvero il meccanismo utilizzato per tradurre i nomi a dominio in indirizzi IP e viceversa.
Tale software era inizialmente nato per fornire il servizio di caching DNS nelle distribuzioni Linux; successivamente sono stati implementati il protocollo DHCP ( Dynamic Host Configuration Protocol ), che consente la configurazione automatica della rete (configurazione automatica degli indirizzi IP sulle macchine connesse alla rete, invio della configurazione DNS, invio di configurazioni extra tramite opzioni DHCP specifiche) e un server TFTP ( Trivial File Transfer Protocol , protocollo molto semplice per il trasferimento dei file), che unitamente a DHCP, permette di effettuare il boot via rete delle macchine (PXE boot).
Caratterizzato da un footprint molto piccolo, da una notevole facilità di configurazione e da prestazioni eccellenti, DNSmasq è quindi diventato lo standard de facto per la configurazione delle reti di piccole dimensioni: è stato dunque implementato in router e dispositivi integrati di rete, in dispositivi Internet-of-Things e nei terminali Android e iOS. È infatti DNSmasq che provvede alla configurazione della rete quando si effettua la condivisione della connessione a Internet (tethering).
Ma non è tutto: DNSmasq è anche il componente su cui fanno affidamento per gli stessi scopi molteplici soluzioni cloud; si pensi, ad esempio, ai noti Open Stack (soluzione Infrastructure as a Service per l’orchestrazione e l’erogazione di risorse su infrastrutture cloud private) e Kubernetes (soluzione Platform as a Service per l’erogazione di servizi cloud a livello di piattaforma, ovvero a supporto di un applicativo, come database, middleware, bilanciatori ecc.). Insomma, DNSmasq è quasi ovunque: nei vostri smartphone come nei vostri router, sul vostro PC di casa come sui server di Google; oltretutto svolge un servizio essenziale, dato che eventuali compromissioni possono facilmente portare a scenari del tutto inaspettati, come la redirezione del traffico Internet, l’installazione di malware e il deploy di configurazioni malevole tramite DHCP.
Come se non bastasse, le vulnerabilità divulgate da Google, sono tutte di severity alta. Si tratta infatti di errori di gestione della memoria, che possono portare a buffer overflow con conseguenti possibilità di denial of service (blocco del funzionamento del servizio), information disclosure o possibilità di esecuzione arbitraria di codice da remoto.
Chi ha più da temere è chi espone un servizio DNS o DHCP al pubblico tramite tale prodotto, come i gestori di reti pubbliche (ad esempio reti wireless in un bar) basate su sistemi open-source (come i comuni router per reti di piccole dimensioni) e i fornitori di servizi cloud, a rischio di attacchi di tipo tenant-on-tenant (dove un utente del servizio cloud può voler scoprire informazioni sulle risorse appartenenti ad un altro utente o negare ad esso il funzionamento del servizio) tenant-on-provider (dove l’utente può attaccare direttamente il fornitore del servizio creando ad esso disagi tramite denial-of-service o eseguire codice arbitrario sull’infrastruttura dello stesso); non sono da escludere tuttavia, scenari di attacco che possano comprendere altre tipologie di attori, considerando anche che DNSmasq è talvolta esposto anche sulla Internet pubblica .
Andiamo dunque ad approfondire ciascuna di tali vulnerabilità.
La CVE-2017-13704 , risiede nei file rfc1035.c (che implementa proprio il protocollo DNS e auth.c , che gestisce le richieste DNS autenticate.
In particolare, nel primo file, la funzione vulnerabile è answer_request , che viene invocata per preparare la risposta della query DNS; nel secondo file, invece, la vulnerabilità è nel metodo answer_auth .
In entrambe le funzioni, infatti, viene chiamata una memset così costituita:
memset(((char *)header) + qlen, 0,
(limit - ((char *)header)) - qlen)
Tale invocazione era stata introdotta come misura di sicurezza, con l’obiettivo di azzerare la memoria e prevenire eventuali leakage di informazioni. Il parametro di interesse è il terzo, ovvero la dimensione della porzione di memoria da settare a 0. Essa è calcolata a partire da limit (puntatore all’ultimo byte valido del buffer) a cui viene sottratto il puntatore all’header della risposta.
La differenza limit - ((char *)header) , pertanto, è esattamente equivalente alla dimensione del buffer. A questo viene sottratta la variabile qlen , ovvero la dimensione della richiesta DNS, che è appesa all’inizio della risposta come da specifica protocollare. Tutto funziona a dovere, se non fosse che nella funzione receive_query del file forward.c , il cui compito è quello di gestire la richiesta DNS non appena arriva al demone ed effettuarne il dispatching verso i due moduli appena citati, il parametro limit è calcolato non come somma di header e lunghezza del buffer, ma come somma dell’header e della dimensione massima attesa per un pacchetto DNS, ovvero 512 bytes (nel caso in cui la richiesta abbia il flag EDNS0 attivo, viene presa la dimensione massima del pacchetto EDNS0).
Possono perciò potenzialmente verificarsi due situazioni distinte: il pacchetto assume una dimensione equivalente a limit , per cui l’effetto della
La patch , sottomessa dallo sviluppatore del progetto Simon Kelley, punta a spostare tale memset direttamente in forward.c , affrontando il problema iniziale a monte ed eliminando la vulnerabilità.
La seconda vulnerabilità è la CVE-2017-14491 . Trattasi di un buffer overflow di 2KB sullo heap; nelle versioni precedenti alla 2.6, la dimensione del buffer sovrascrivibile era addirittura illimitata.
Salvo protezioni a livello kernel o attuate dal compilatore, la vulnerabilità può potenzialmente consentire l’esecuzione di codice remoto da parte di chiunque sia abilitato ad effettuare query DNS verso un dominio sotto al proprio controllo. La funzione vulnerabile è add_resource_record , che effettua il parsing della risposta in arrivo dal server DNS remoto per poi costruire i resource record da mettere in cache per la successiva interrogazione da parte del client.
Nell’implementazione non viene tenuto conto delle grandezze effettivamente attese per i vari tipi di dato. In particolare, nel momento in cui il formato del dato è di tipo “d” (dominio), viene invocata la funzione do_rfc1035_name che effettua una copia del buffer in un’altra variabile in modo totalmente incontrollato. L’obiettivo della patch è quindi quello di definire una macro ( CHECK_LIMIT ) per controllare la lunghezza dei vari campi. È stato inoltre aggiunto l’argomento limit alla funzione do_rfc1035_name per consentire l’esecuzione del medesimo controllo; tutte le invocazioni di tale funzione che non necessitano di tale argomento sono state infine adattate per rispondere alla nuova segnatura aggiungendovi il valore NULL .
La vulnerabilità espone dunque DNSmasq ad una potenziale remote code execution che, qualora fallisca, porta al crash del processo. Per tale problematica Google ha fornito un PoC disponibile a questo link con annesse istruzioni .
Anche la CVE-2017-14492 è una remote code execution basata su buffer overflow sullo heap. Questa volta le funzionalità colpite sono quelle relative all’implementazione del router advertisement (fase del neighbor discovery protocol, utilizzato per l’autoconfigurazione degli indirizzi tramite ICMP in reti basate su IP versione 6). Per scatenare la vulnerabilità è possibile utilizzare una richiesta di router advertisement appositamente forgiata, come si può vedere dal PoC rilasciato da Mountain View .
Analogamente, la CVE-2017-14493 è un buffer overflow che colpisce la funzionalità di relaying di DHCPv6 in rfc3315.c , nella funzione dhcp6_maybe_relay , nel momento in cui viene trattato l’indirizzo di livello 2 del client non viene effettuato il controllo sulla lunghezza del buffer. La memcpy successiva, pertanto, effettua un accesso incontrollato al buffer. Curioso è il commento dello sviluppatore posto in testa a tale funzione:
/* This cost me blood to write, it will probably cost you blood to understand - srk. */
Ancora una volta, l’attaccante può forgiare una richiesta così da mandare in crash l’applicativo come illustrato nel proof-of-concept relativo , per eseguire codice arbitrario, tuttavia, è necessario sfruttarla in congiunzione con la CVE-2017-14494 .
Quest’ultima, dovuta anch’essa alla sanguinolenta funzione appena discussa, consente un leakage di informazioni dalla RAM; la 14493 e la 14494 possono perciò potenzialmente portare all’esecuzione di codice arbitrario bypassando eventuali protezioni imposte dal kernel, come la casualizzazione dello spazio degli indirizzi ( ASLR, address space layout randomization ).
La CVE-2017-14495 è invece una vulnerabilità dall’impatto limitato, dovuta a uno spreco di memoria per la mancanza di una free nella funzione add_pseudoheader di edns0.c , e può portare a un denial of service per esaurimento della memoria. La parte di codice vulnerabile è raggiungibile solo se DNSmasq è stato avviato con gli switch --add-mac , --add-cpe-id o --add-subnet ; come mostrato dal PoC , l’attaccante può inviare una richiesta DNS appositamente forgiata per scatenare la vulnerabilità.
La medesima funzione nasconde anche una integer underflow, anch’essa raggiungibile solo in presenza degli switch sopra citati, che comporta l’esecuzione di una memcpy molto grande con conseguente crash del servizio alla somministrazione di un pacchetto appositamente costruito. Questa problematica, mostrata in quest’ultimo PoC , è presente nel tethering Android; tuttavia, poiché il servizio DNSmasq viene avviato in una sandbox, il rischio è notevolmente ridotto per gli utenti del sistema operativo di Google. In ogni caso, chiunque installerà l’aggiornamento delle definizioni di sicurezza di Ottobre per Android sarà al sicuro anche da tale vulnerabilità.
Le patch per tutte le vulnerabilità sono state infatti caricate nel repository GIT del progetto; Google, oltretutto, ha sottomesso un’ulteriore patch per far eseguire DNSmasq sotto seccomp-bpf (sandbox a livello kernel già utilizzata per proteggere OpenSSH – noto software che implementa il protocollo SSH per l’accesso remoto ai sistemi – vsftpd – demone per il protocollo ftp – e Chromium , il progetto opensource alla base del browser Google Chrome).
Oltre alle patch per Android, Google ha rilasciato un aggiornamento al pod DNS anche per Kubernetes 1.5.8, 1.6.11, 1.7.7 e 1.8.0.
L’aggiornamento a DNSmasq 2.78 è quindi fortemente consigliato anche in tutte le altre realtà; ove possibile si raccomanda l’upgrade del firmware dei propri router e dei pacchetti su tutti i dispositivi che eseguano tale software.
Patrizio Tufarolo
Ti potrebbe interessare
5 ott 2017