Ieri vi ho parlato in maniera piuttosto esaustiva di questo bug, e vi ho lasciato anche l’indirizzo a cui trovare l’exploit costruito ad hoc. Oggi voglio suggerire un piccolo workaround per Debian, Ubuntu e le distribuzioni debian-based, workaround che ho messo a punto (con qualche aiuto esterno) poche ore fa, e che annulla la vulnerabilità del kernel relativa ai permessi su /proc/<pid>/mem. Quindi se per qualche motivo gli aggiornamenti di sistema non avessero risolto il vostro problema, o se non riuscite a ricompilare il kernel utilizzando il codice sorgente presente su kernel.org, allora questo è il post che fa per voi.
Un minimo di spiegazione: andremo ad applicare il fix utilizzando le immagini create per il debugging del kernel, il debugger systemtap ed il suo front-end stap. Non sto qui a scrivere il come, il quando ed il perchè (sarebbe un discorso lunghissimo e quantomeno incomprensibile a chi non è pratico della materia) ma mi limito ad illustrarvi il procedimento. Resto comunque disponibile per ulteriori chiarimenti, qualora non doveste fidarvi!
Come primo step andremo a scaricare lo stesso systemtap e qualche dipendenza per giocare con stap e con il kernel, aprendo un terminale e digitando
sudo apt-get install systemtap dpkg-dev
dopodichè scarichiamo l’immagine di debugging (quella contenente i cosiddetti symbols) appropriata al nostro kernel, con il comando (andate a prendere un caffè intanto, sono quasi 700MB di roba)
wget http://ddebs.ubuntu.com/pool/main/l/linux/$(dpkg -l linux-image-$(uname -r) | grep ^ii | awk '{print $2 "-dbgsym_" $3}' | tail -n1)_$(dpkg-architecture -qDEB_HOST_ARCH).ddeb
ed installiamola, con il comando
sudo dpkg -i linux-image-$(uname -r)*-dbgsym.ddeb
Completata l’installazione possiamo eliminare il pacchetto per recuperare spazio, con il comando
sudo rm linux-image-$(uname -r)*-dbgsym.ddeb
Adesso abbiamo la nostra immagine per debugging installata, ora andiamo a creare il nostro script systemtap che bloccherà la scrittura incriminata. Sempre da terminale, digitiamo
gedit CVE0056.stp
Scriviamo, all’interno del documento, le righe
probe kernel.function("mem_write@fs/proc/base.c").call {
$count = 0
}
Io ho utilizzato gedit, ma voi potrete utilizzare l’editor che più preferite.
Salviamo e chiudiamo. Ora, dal nostro script, dobbiamo creare (senza caricarlo, però) un kernel object, che noi useremo però a mò di modulo vero e proprio (ve l’ho detto che è un workaround :) ). Quindi, sempre da terminale, scriviamo
sudo stap -g -m cve0056 CVE0056.stp -p4
Avremo così ottenuto il file .ko, tale cve0056.ko. A questo punto creiamo una directory per renderlo utilizzabile, tutto ciò per evitare di specificare parametri e percorsi addizionali. Sempre da terminale digitiamo
sudo mkdir -p /lib/modules/$(uname -r)/systemtap
Copiamo il file .ko appena creato all’interno della suddetta directory, con il comando
sudo cp cve0056.ko /lib/modules/$(uname -r)/systemtap
Non ci crederete ma… la fine è vicina. Iniziamo con il caricare il “modulo fantoccio” scrivendo, sempre da terminale,
sudo staprun -L cve0056
Ora riprovate ad eseguire l’exploit sul vostro computer: vedrete che il vostro kernel non è più vulnerabile! Ora abbiamo un’ultima cosa da fare: aggiungere staprun alle applicazioni d’avvio. Per far ciò digitiamo, sempre da terminale
gedit /etc/rc.local
e, nella riga precedente a exit 0 inserite il seguente codice:
staprun -L cve0056
NB: qualora doveste cambiare la vostra versione del kernelsarebbe buona norma eliminare la suddetta riga da rc.local. E’ tutto!