Il bug CVE-2015-7547 nella libreria glibc e sua soluzione

E' notizia di pochi giorni fa che Linux è affetto da un pesante bug nelle sua libreria glibc (libreria standard C progetto GNU). Il bug è considerato a rischio elevato e ne sono affette tutte le versioni glibc a partire dalla 2.9 fino alla 2.22, quindi praticamente da circa 7 anni. Per conoscere che versione gira di glibc sulla vostra distro date da terminale il comando ldd --version. Il bug è piuttosto grave perchè rende vulnerabile ad intrusioni di un certo peso tutte le macchine con installato il sistema operativo Linux. Peraltro già nel 2015 s'era avuto sentore del bug senza prendere provvedimenti. Ad individuare definitivamente il bug è stato il team di Google e di RedHat. Senza andare troppo nel tecnico, dato che la materia è alquanto ostica e sta dando luogo ad accese discussioni con opinioni contrastanti su internet, ci si domanda: il semplice utente Linux in un uso desktop del sistema operativo che deve fare? Premessa essenziale è dire che il problema in questione è ovviamente più grave qualora ci sia da gestire un server. Per chi volesse comunque una analisi tecnica accurata sul bug, può leggersi queste pagine scritte proprio dal team RedHat per la patch. Per una normale utenza lato desktop diciamo subito che la prima cosa da fare è aggiornare il prima possibile la libreria in questione. Peraltro non tutte le distro Linux sembrano affette dal bug, ad esempio Slackware pare avesse già risolto a suo tempo la cosa. Chi usa invece Debian, Ubuntu, OpenSuse e relative derivate ha l'obbligo assoluto di aggiornare il più presto possibile glibc. Si segnala che sotto qualche distro (ad esempio Ubuntu) la libreria glibc viene denominata con libc6 (cioè la versione 2 di glibc). Per aggiornare, è utile quest'articolo di riferimento che, seppure in inglese, spiega in modo semplice come aggiornare queste distribuzioni ed applicare quindi la patch necessaria a risolvere il problema. Per altre distibuzioni è meglio ricercare sulla rete notizie specifiche alla propria distro. Alla fine dell'update, se proprio volete essere sicuri di avere aggiornato con la patch, potete andare nell'interfaccia grafica (oppure usare gli appositi comandi da terminale) della gestione software delle varie distro e, selezionando il pacchetto glibc, analizzarne le proprietà. Dovreste vedere un'avvertenza più o meno di questo tono: "send-dg-buffer-overflow.patch: Fix getaddrinfo stack-based buffer overflow (CVE-2015-7547)" o scritte analoghe. 

Ma si risolve del tutto il problema con l'aggiornamento di glibc? Qui sta l'aspetto più inquietante, dato che, nelle discussioni in rete, qualcuno adombra la tesi, peraltro controversa, che sia addirittura necessaria una ricompilazione di molti programmi per essere veramente sicuri di aver risolto. Se fosse vero, questo creerebbe non pochi inconvenienti. In questo caso, all'utente normale Linux non resterebbe che sperare negli aggiornamenti futuri degli applicativi e forse pensare ad una reinstallazione con una versione più recente del sistema operativo e relativi programmi gestionali da farsi magari tra qualche tempo. 

Per i più intraprendenti è possibile scaricare da QUI un tool proveniente dal team Google (detto POC) che con due semplici programmi in C e in Python dovrebbe testare la bontà delle vostra libreria glibc. Fare il download del file .zip (tasto in alto a destra) e scompattarlo, meglio se in un'apposita directory nuova creata.  Fatto questo nella cartella creata avrete un programma con il suffisso .c  lato client e in .py  lato server. Bisogna, da terminale, compilare prima il file con suffisso .c con il comando da terminale gcc -o client CVE-2015-7547-client.c. Poi eseguire il programma in python (da amministratore in un terminale) con il comando python CVE-2015-7547-poc.py. Fate attenzione alla versione python che usate (versione 2 o 3) dato che non sempre la sintassi è analoga. Qui bisogna usare la versione 2 (eventualmente scrivendo python2 al posto di python). Eseguito il programma in python in un'altra scheda del terminale scrivete ./client: se tutto e Ok non dovrebbe andare in crash nulla e il terminale lato client dovrebbe rispondere in modo silente, praticamente non  appare nulla sul terminale.

Gli utilizzatori di Android, nonostante l'uso del kernel Linux, possono stare tranquilli dato che Android non s'avvale della libreria glibc ma di un'altra libreria di Google C standard denominata bionic. Anche per i sistemi *BSD (compreso MacOsX e iOS) non ci sono problemi, se non nel caso di compilazione specifica da parte dell'utente con la libreria GNU glibc (gcc) di applicativi Linux, come in FreeBSD ecc. Per utenti FreeBSD è utile comunque dare una letta QUI. Ovviamente e duole dirlo, Windows è stavolta esente da pecche, a meno che un utente Windows non abbia forse usato MinGW, cioè un porting compilatore gcc su piattaforma Windows ma per i normali utenti lo ritengo altamente improbabile...

A questo punto una considerazione finale è d'obbligo.  La notizia è in effetti sconcertante. Seppure il sistema operativo sicuro al 100% non esista, questo bug bisogna ammettere che è un duro colpo all'affidabilità Linux (soprattutto lato server), specie per la modalità con cui è stato gestito, anzi non gestito. Sembra essere saltata in questo vicenda una delle prerogative di Linux e del software libero: eventuali bug e pecche nel software sono, per la natura stessa dell'open source, rapidamente risolti in tempi più brevi del normale software proprietario e/o closed. Stavolta tutto questo non ha proprio funzionato, tanto che malignamente il responsabile della sicurezza di Google Chrome Chris Palmer ha pesantemente commentato su Twitter  l'accaduto.